Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
50ae406553
commit
536aa3a1f4
|
@ -5,6 +5,14 @@ import { ApolloLink } from 'apollo-link';
|
|||
import { BatchHttpLink } from 'apollo-link-batch-http';
|
||||
import csrf from '~/lib/utils/csrf';
|
||||
|
||||
export const fetchPolicies = {
|
||||
CACHE_FIRST: 'cache-first',
|
||||
CACHE_AND_NETWORK: 'cache-and-network',
|
||||
NETWORK_ONLY: 'network-only',
|
||||
NO_CACHE: 'no-cache',
|
||||
CACHE_ONLY: 'cache-only',
|
||||
};
|
||||
|
||||
export default (resolvers = {}, config = {}) => {
|
||||
let uri = `${gon.relative_url_root}/api/graphql`;
|
||||
|
||||
|
@ -32,5 +40,10 @@ export default (resolvers = {}, config = {}) => {
|
|||
}),
|
||||
resolvers,
|
||||
assumeImmutableResults: config.assumeImmutableResults,
|
||||
defaultOptions: {
|
||||
query: {
|
||||
fetchPolicy: config.fetchPolicy || fetchPolicies.CACHE_FIRST,
|
||||
},
|
||||
},
|
||||
});
|
||||
};
|
||||
|
|
|
@ -1,8 +1,13 @@
|
|||
import { omit } from 'lodash';
|
||||
import createGqClient from '~/lib/graphql';
|
||||
import createGqClient, { fetchPolicies } from '~/lib/graphql';
|
||||
import { getIdFromGraphQLId } from '~/graphql_shared/utils';
|
||||
|
||||
export const gqClient = createGqClient();
|
||||
export const gqClient = createGqClient(
|
||||
{},
|
||||
{
|
||||
fetchPolicy: fetchPolicies.NO_CACHE,
|
||||
},
|
||||
);
|
||||
|
||||
export const uniqMetricsId = metric => `${metric.metric_id}_${metric.id}`;
|
||||
|
||||
|
|
|
@ -63,11 +63,6 @@
|
|||
background-color: $gray-normal;
|
||||
}
|
||||
|
||||
a,
|
||||
button {
|
||||
color: $gray-700;
|
||||
}
|
||||
|
||||
svg {
|
||||
vertical-align: middle;
|
||||
top: -1px;
|
||||
|
|
|
@ -4,9 +4,15 @@ module Projects
|
|||
module Serverless
|
||||
class FunctionsFinder
|
||||
include Gitlab::Utils::StrongMemoize
|
||||
include ReactiveCaching
|
||||
|
||||
attr_reader :project
|
||||
|
||||
self.reactive_cache_key = ->(finder) { finder.cache_key }
|
||||
self.reactive_cache_worker_finder = ->(_id, *args) { from_cache(*args) }
|
||||
|
||||
MAX_CLUSTERS = 10
|
||||
|
||||
def initialize(project)
|
||||
@project = project
|
||||
end
|
||||
|
@ -15,8 +21,9 @@ module Projects
|
|||
knative_services.flatten.compact
|
||||
end
|
||||
|
||||
# Possible return values: Clusters::KnativeServicesFinder::KNATIVE_STATE
|
||||
def knative_installed
|
||||
return knative_installed_from_cluster?(*cache_key) if available_environments.empty?
|
||||
|
||||
states = services_finders.map do |finder|
|
||||
finder.knative_detected.tap do |state|
|
||||
return state if state == ::Clusters::KnativeServicesFinder::KNATIVE_STATES['checking'] # rubocop:disable Cop/AvoidReturnFromBlocks
|
||||
|
@ -45,8 +52,41 @@ module Projects
|
|||
end
|
||||
end
|
||||
|
||||
def self.from_cache(project_id)
|
||||
project = Project.find(project_id)
|
||||
|
||||
new(project)
|
||||
end
|
||||
|
||||
def cache_key(*args)
|
||||
[project.id]
|
||||
end
|
||||
|
||||
def calculate_reactive_cache(*)
|
||||
# rubocop: disable CodeReuse/ActiveRecord
|
||||
project.all_clusters.enabled.take(MAX_CLUSTERS).any? do |cluster|
|
||||
cluster.kubeclient.knative_client.discover
|
||||
rescue Kubeclient::ResourceNotFoundError
|
||||
next
|
||||
end
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def knative_installed_from_cluster?(*cache_key)
|
||||
cached_data = with_reactive_cache_memoized(*cache_key) { |data| data }
|
||||
|
||||
return ::Clusters::KnativeServicesFinder::KNATIVE_STATES['checking'] if cached_data.nil?
|
||||
|
||||
cached_data ? true : false
|
||||
end
|
||||
|
||||
def with_reactive_cache_memoized(*cache_key)
|
||||
strong_memoize(:reactive_cache) do
|
||||
with_reactive_cache(*cache_key) { |data| data }
|
||||
end
|
||||
end
|
||||
|
||||
def knative_service(environment_scope, name)
|
||||
finders_for_scope(environment_scope).map do |finder|
|
||||
services = finder
|
||||
|
@ -95,6 +135,10 @@ module Projects
|
|||
environment_scope == finder.cluster.environment_scope
|
||||
end
|
||||
end
|
||||
|
||||
def id
|
||||
nil
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
@ -19,6 +19,18 @@ module ExploreHelper
|
|||
request_path_with_options(options)
|
||||
end
|
||||
|
||||
def filter_audit_path(options = {})
|
||||
exist_opts = {
|
||||
entity_type: params[:entity_type],
|
||||
entity_id: params[:entity_id],
|
||||
created_before: params[:created_before],
|
||||
created_after: params[:created_after],
|
||||
sort: params[:sort]
|
||||
}
|
||||
options = exist_opts.merge(options).delete_if { |key, value| value.blank? }
|
||||
request_path_with_options(options)
|
||||
end
|
||||
|
||||
def filter_groups_path(options = {})
|
||||
request_path_with_options(options)
|
||||
end
|
||||
|
|
|
@ -207,6 +207,13 @@ module SortingHelper
|
|||
}.merge(issuable_sort_option_overrides)
|
||||
end
|
||||
|
||||
def audit_logs_sort_order_hash
|
||||
{
|
||||
sort_value_recently_created => sort_title_recently_created,
|
||||
sort_value_oldest_created => sort_title_oldest_created
|
||||
}
|
||||
end
|
||||
|
||||
def issuable_sort_option_title(sort_value)
|
||||
sort_value = issuable_sort_option_overrides[sort_value] || sort_value
|
||||
|
||||
|
|
|
@ -13,6 +13,8 @@ class AuditEvent < ApplicationRecord
|
|||
|
||||
scope :by_entity_type, -> (entity_type) { where(entity_type: entity_type) }
|
||||
scope :by_entity_id, -> (entity_id) { where(entity_id: entity_id) }
|
||||
scope :order_by_id_desc, -> { order(id: :desc) }
|
||||
scope :order_by_id_asc, -> { order(id: :asc) }
|
||||
|
||||
after_initialize :initialize_details
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
module Clusters
|
||||
module Applications
|
||||
class Runner < ApplicationRecord
|
||||
VERSION = '0.13.0'
|
||||
VERSION = '0.13.1'
|
||||
|
||||
self.table_name = 'clusters_applications_runners'
|
||||
|
||||
|
|
|
@ -1,73 +0,0 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AkismetService
|
||||
attr_accessor :text, :options
|
||||
|
||||
def initialize(owner_name, owner_email, text, options = {})
|
||||
@owner_name = owner_name
|
||||
@owner_email = owner_email
|
||||
@text = text
|
||||
@options = options
|
||||
end
|
||||
|
||||
def spam?
|
||||
return false unless akismet_enabled?
|
||||
|
||||
params = {
|
||||
type: 'comment',
|
||||
text: text,
|
||||
created_at: DateTime.now,
|
||||
author: owner_name,
|
||||
author_email: owner_email,
|
||||
referrer: options[:referrer]
|
||||
}
|
||||
|
||||
begin
|
||||
is_spam, is_blatant = akismet_client.check(options[:ip_address], options[:user_agent], params)
|
||||
is_spam || is_blatant
|
||||
rescue => e
|
||||
Rails.logger.error("Unable to connect to Akismet: #{e}, skipping check") # rubocop:disable Gitlab/RailsLogger
|
||||
false
|
||||
end
|
||||
end
|
||||
|
||||
def submit_ham
|
||||
submit(:ham)
|
||||
end
|
||||
|
||||
def submit_spam
|
||||
submit(:spam)
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
attr_accessor :owner_name, :owner_email
|
||||
|
||||
def akismet_client
|
||||
@akismet_client ||= ::Akismet::Client.new(Gitlab::CurrentSettings.akismet_api_key,
|
||||
Gitlab.config.gitlab.url)
|
||||
end
|
||||
|
||||
def akismet_enabled?
|
||||
Gitlab::CurrentSettings.akismet_enabled
|
||||
end
|
||||
|
||||
def submit(type)
|
||||
return false unless akismet_enabled?
|
||||
|
||||
params = {
|
||||
type: 'comment',
|
||||
text: text,
|
||||
author: owner_name,
|
||||
author_email: owner_email
|
||||
}
|
||||
|
||||
begin
|
||||
akismet_client.public_send(type, options[:ip_address], options[:user_agent], params) # rubocop:disable GitlabSecurity/PublicSend
|
||||
true
|
||||
rescue => e
|
||||
Rails.logger.error("Unable to connect to Akismet: #{e}, skipping!") # rubocop:disable Gitlab/RailsLogger
|
||||
false
|
||||
end
|
||||
end
|
||||
end
|
|
@ -6,7 +6,7 @@ module AkismetMethods
|
|||
end
|
||||
|
||||
def akismet
|
||||
@akismet ||= AkismetService.new(
|
||||
@akismet ||= Spam::AkismetService.new(
|
||||
spammable_owner.name,
|
||||
spammable_owner.email,
|
||||
spammable.spammable_text,
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
module Notes
|
||||
class UpdateService < BaseService
|
||||
def execute(note)
|
||||
return note unless note.editable?
|
||||
return note unless note.editable? && params.present?
|
||||
|
||||
old_mentioned_users = note.mentioned_users(current_user).to_a
|
||||
|
||||
|
|
|
@ -0,0 +1,75 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Spam
|
||||
class AkismetService
|
||||
attr_accessor :text, :options
|
||||
|
||||
def initialize(owner_name, owner_email, text, options = {})
|
||||
@owner_name = owner_name
|
||||
@owner_email = owner_email
|
||||
@text = text
|
||||
@options = options
|
||||
end
|
||||
|
||||
def spam?
|
||||
return false unless akismet_enabled?
|
||||
|
||||
params = {
|
||||
type: 'comment',
|
||||
text: text,
|
||||
created_at: DateTime.now,
|
||||
author: owner_name,
|
||||
author_email: owner_email,
|
||||
referrer: options[:referrer]
|
||||
}
|
||||
|
||||
begin
|
||||
is_spam, is_blatant = akismet_client.check(options[:ip_address], options[:user_agent], params)
|
||||
is_spam || is_blatant
|
||||
rescue => e
|
||||
Rails.logger.error("Unable to connect to Akismet: #{e}, skipping check") # rubocop:disable Gitlab/RailsLogger
|
||||
false
|
||||
end
|
||||
end
|
||||
|
||||
def submit_ham
|
||||
submit(:ham)
|
||||
end
|
||||
|
||||
def submit_spam
|
||||
submit(:spam)
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
attr_accessor :owner_name, :owner_email
|
||||
|
||||
def akismet_client
|
||||
@akismet_client ||= ::Akismet::Client.new(Gitlab::CurrentSettings.akismet_api_key,
|
||||
Gitlab.config.gitlab.url)
|
||||
end
|
||||
|
||||
def akismet_enabled?
|
||||
Gitlab::CurrentSettings.akismet_enabled
|
||||
end
|
||||
|
||||
def submit(type)
|
||||
return false unless akismet_enabled?
|
||||
|
||||
params = {
|
||||
type: 'comment',
|
||||
text: text,
|
||||
author: owner_name,
|
||||
author_email: owner_email
|
||||
}
|
||||
|
||||
begin
|
||||
akismet_client.public_send(type, options[:ip_address], options[:user_agent], params) # rubocop:disable GitlabSecurity/PublicSend
|
||||
true
|
||||
rescue => e
|
||||
Rails.logger.error("Unable to connect to Akismet: #{e}, skipping!") # rubocop:disable Gitlab/RailsLogger
|
||||
false
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
|
@ -22,7 +22,7 @@
|
|||
%span.board-title-main-text.block-truncated{ "v-if": "list.type !== \"label\"",
|
||||
":title" => '((list.label && list.label.description) || list.title || "")',
|
||||
data: { container: "body" },
|
||||
":class": "{ 'has-tooltip': !['backlog', 'closed'].includes(list.type) }" }
|
||||
":class": "{ 'has-tooltip': !['backlog', 'closed'].includes(list.type), 'd-block': list.type === 'milestone' }" }
|
||||
{{ list.title }}
|
||||
|
||||
%span.board-title-sub-text.prepend-left-5.has-tooltip{ "v-if": "list.type === \"assignee\"",
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Allow long milestone titles on board lists to be truncated
|
||||
merge_request:
|
||||
author:
|
||||
type: fixed
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Fix JIRA::HTTPError initialize parameter
|
||||
merge_request: 24060
|
||||
author:
|
||||
type: fixed
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Remove gray color from diff buttons
|
||||
merge_request: 24041
|
||||
author:
|
||||
type: fixed
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add separate classes for project related classes
|
||||
merge_request: 23887
|
||||
author: Rajendra Kadam
|
||||
type: added
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Update GitLab Runner Helm Chart to 0.13.1 (GitLab Runner 12.7.1)
|
||||
merge_request: 23588
|
||||
author:
|
||||
type: other
|
|
@ -0,0 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# This file requires config/initializers/1_settings.rb
|
||||
|
||||
if Rails.env.development?
|
||||
Rails.application.config.hosts << Gitlab.config.gitlab.host
|
||||
end
|
|
@ -144,7 +144,7 @@ the steps bellow.
|
|||
|
||||
1. Enter the Rails console:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rails console
|
||||
```
|
||||
|
||||
|
|
|
@ -14,13 +14,13 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
|
|||
|
||||
For omnibus installation
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
||||
For installations from source:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
|
||||
```
|
||||
|
||||
|
|
|
@ -20,13 +20,13 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
|
|||
|
||||
**Omnibus:**
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
||||
**Source:**
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
|
||||
sudo -u git -H editor config/gitlab.yml
|
||||
|
|
|
@ -149,7 +149,7 @@ You can use the [`AdFind`](https://social.technet.microsoft.com/wiki/contents/ar
|
|||
|
||||
You can use the filter `objectclass=*` to return all directory objects.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -up Password1 -b "OU=GitLab INT,DC=GitLab,DC=org" -f (objectClass=*)
|
||||
```
|
||||
|
||||
|
@ -157,7 +157,7 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
|
|||
|
||||
You can also retrieve a single object by **specifying** the object name or full **DN**. In this example we specify the object name only `CN=Leroy Fox`.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -up Password1 -b "OU=GitLab INT,DC=GitLab,DC=org" -f (&(objectcategory=person)(CN=Leroy Fox))”
|
||||
```
|
||||
|
||||
|
@ -169,7 +169,7 @@ You can use the `ldapsearch` utility (on Unix based systems) to test that your L
|
|||
|
||||
You can use the filter `objectclass=*` to return all directory objects.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" \
|
||||
-w Password1 -p 636 -h ad.example.org \
|
||||
-b "OU=GitLab INT,DC=GitLab,DC=org" -Z \
|
||||
|
@ -180,7 +180,7 @@ ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" \
|
|||
|
||||
You can also retrieve a single object by **specifying** the object name or full **DN**. In this example we specify the object name only `CN=Leroy Fox`.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -w Password1 -p 389 -h ad.example.org -b "OU=GitLab INT,DC=GitLab,DC=org" -Z -s sub "CN=Leroy Fox"
|
||||
```
|
||||
|
||||
|
|
|
@ -11,13 +11,13 @@ JWT will provide you with a secret key for you to use.
|
|||
|
||||
For Omnibus GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
||||
For installations from source:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H editor config/gitlab.yml
|
||||
```
|
||||
|
|
|
@ -465,7 +465,7 @@ step of the sync.
|
|||
|
||||
1. Start a Rails console:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# For Omnibus installations
|
||||
sudo gitlab-rails console
|
||||
|
||||
|
@ -540,7 +540,7 @@ statements.
|
|||
|
||||
Indicates the point where syncing actually begins:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
Started syncing all providers for 'my_group' group
|
||||
```
|
||||
|
||||
|
@ -551,7 +551,7 @@ log entries like this - one for each LDAP group. If you don't see an LDAP user
|
|||
DN in this log entry, LDAP is not returning the user when we do the lookup.
|
||||
Verify the user is actually in the LDAP group.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
|
||||
"uid=mary0,ou=people,dc=example,dc=com", "uid=john1,ou=people,dc=example,dc=com",
|
||||
"uid=mary1,ou=people,dc=example,dc=com", "uid=john2,ou=people,dc=example,dc=com",
|
||||
|
@ -571,7 +571,7 @@ NOTE: **Note:**
|
|||
10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
|
||||
and 50 is 'Owner'.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
Resolved 'my_group' group member access: {"uid=john0,ou=people,dc=example,dc=com"=>30,
|
||||
"uid=mary0,ou=people,dc=example,dc=com"=>30, "uid=john1,ou=people,dc=example,dc=com"=>30,
|
||||
"uid=mary1,ou=people,dc=example,dc=com"=>30, "uid=john2,ou=people,dc=example,dc=com"=>30,
|
||||
|
@ -588,7 +588,7 @@ If you think a particular user should already exist in GitLab, but you're seeing
|
|||
this entry, it could be due to a mismatched DN stored in GitLab. See
|
||||
[User DN has changed](#User-DN-has-changed) to update the user's LDAP identity.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
User with DN `uid=john0,ou=people,dc=example,dc=com` should have access
|
||||
to 'my_group' group but there is no user in GitLab with that
|
||||
identity. Membership will be updated once the user signs in for
|
||||
|
@ -597,6 +597,6 @@ the first time.
|
|||
|
||||
Finally, the following entry says syncing has finished for this group:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
Finished syncing all providers for 'my_group' group
|
||||
```
|
||||
|
|
|
@ -564,7 +564,7 @@ This example uses `ldapsearch` and assumes you are using ActiveDirectory. The
|
|||
following query returns the login names of the users that will be allowed to
|
||||
log in to GitLab if you configure your own user_filter.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$base" "$user_filter" sAMAccountName
|
||||
```
|
||||
|
||||
|
@ -583,7 +583,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$ba
|
|||
- Run the following check command to make sure that the LDAP settings are
|
||||
correct and GitLab can see your users:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# For Omnibus installations
|
||||
sudo gitlab-rake gitlab:ldap:check
|
||||
|
||||
|
|
|
@ -13,13 +13,13 @@ The OpenID Connect will provide you with a client details and secret for you to
|
|||
|
||||
For Omnibus GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
||||
For installations from source:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H editor config/gitlab.yml
|
||||
```
|
||||
|
|
|
@ -46,13 +46,13 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
|
|||
|
||||
**For Omnibus GitLab installations**
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
||||
**For installations from source**
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H editor config/gitlab.yml
|
||||
```
|
||||
|
|
|
@ -94,7 +94,7 @@ The rake task will use a sample data and execute each of file hook. The output
|
|||
should be enough to determine if the system sees your file hook and if it was
|
||||
executed without errors.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Omnibus installations
|
||||
sudo gitlab-rake file_hooks:validate
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ the node more time before scheduling a planned failover.
|
|||
|
||||
Run the following commands in a Rails console on the **primary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rails console
|
||||
```
|
||||
|
||||
|
@ -95,7 +95,7 @@ The automatic background re-verification is enabled by default, but you can
|
|||
disable if you need. Run the following commands in a Rails console on the
|
||||
**primary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rails console
|
||||
```
|
||||
|
||||
|
@ -120,13 +120,13 @@ to be resynced without the backoff period:
|
|||
|
||||
For repositories:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake geo:verification:repository:reset
|
||||
```
|
||||
|
||||
For wikis:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake geo:verification:wiki:reset
|
||||
```
|
||||
|
||||
|
@ -146,25 +146,25 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
|
|||
(the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
|
||||
is customized, check the directory layout on your server to be sure.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /var/opt/gitlab/git-data/repositories
|
||||
```
|
||||
|
||||
1. Run the following command on the **primary** node, redirecting the output to a file:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-node-refs
|
||||
```
|
||||
|
||||
1. Run the following command on the **secondary** node, redirecting the output to a file:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-node-refs
|
||||
```
|
||||
|
||||
1. Copy the files from the previous steps on the same system, and do a diff between the contents:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
diff primary-node-refs secondary-node-refs
|
||||
```
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ To bring the former **primary** node up to date:
|
|||
1. SSH into the former **primary** node that has fallen behind.
|
||||
1. Make sure all the services are up:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl start
|
||||
```
|
||||
|
||||
|
|
|
@ -39,13 +39,13 @@ must disable the **primary** node.
|
|||
|
||||
1. SSH into the **primary** node to stop and disable GitLab, if possible:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl stop
|
||||
```
|
||||
|
||||
Prevent GitLab from starting up again if the server unexpectedly reboots:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo systemctl disable gitlab-runsvdir
|
||||
```
|
||||
|
||||
|
@ -54,7 +54,7 @@ must disable the **primary** node.
|
|||
started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
|
||||
It may be safest to uninstall the GitLab package completely:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
yum remove gitlab-ee
|
||||
```
|
||||
|
||||
|
@ -63,7 +63,7 @@ must disable the **primary** node.
|
|||
or any other distro based on the Upstart init system, you can prevent GitLab
|
||||
from starting if the machine reboots by doing the following:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
initctl stop gitlab-runsvvdir
|
||||
echo 'manual' > /etc/init/gitlab-runsvdir.override
|
||||
initctl reload-configuration
|
||||
|
@ -100,7 +100,7 @@ Note the following when promoting a secondary:
|
|||
|
||||
1. SSH in to your **secondary** node and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -117,7 +117,7 @@ Note the following when promoting a secondary:
|
|||
|
||||
1. Promote the **secondary** node to the **primary** node. Execute:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl promote-to-primary-node
|
||||
```
|
||||
|
||||
|
@ -135,7 +135,7 @@ do this manually.
|
|||
1. SSH in to the database node in the **secondary** and trigger PostgreSQL to
|
||||
promote to read-write:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-pg-ctl promote
|
||||
```
|
||||
|
||||
|
@ -157,7 +157,7 @@ do this manually.
|
|||
1. Promote the **secondary** to **primary**. SSH into a single application
|
||||
server and execute:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake geo:set_secondary_as_primary
|
||||
```
|
||||
|
||||
|
@ -173,7 +173,7 @@ secondary domain, like changing Git remotes and API URLs.
|
|||
|
||||
1. SSH into the **secondary** node and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -192,13 +192,13 @@ secondary domain, like changing Git remotes and API URLs.
|
|||
|
||||
1. Reconfigure the **secondary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Execute the command below to update the newly promoted **primary** node URL:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake geo:update_primary_node_url
|
||||
```
|
||||
|
||||
|
@ -223,7 +223,7 @@ Because the **secondary** is already promoted, that data in the tracking databas
|
|||
|
||||
The data can be removed with the following command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo rm -rf /var/opt/gitlab/geo-postgresql
|
||||
```
|
||||
|
||||
|
@ -237,7 +237,7 @@ and after that you also need two extra steps.
|
|||
|
||||
1. SSH into the new **primary** node and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -268,13 +268,13 @@ and after that you also need two extra steps.
|
|||
1. Save the file and reconfigure GitLab for the database listen changes and
|
||||
the replication slot changes to be applied.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
Restart PostgreSQL for its changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl restart postgresql
|
||||
```
|
||||
|
||||
|
@ -289,7 +289,7 @@ and after that you also need two extra steps.
|
|||
|
||||
Save the file and reconfigure GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
|
|
@ -65,7 +65,7 @@ supports everything the **primary** node does **before** scheduling a planned fa
|
|||
|
||||
Run the following on both **primary** and **secondary** nodes:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake gitlab:check
|
||||
gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
@ -79,7 +79,7 @@ The SSH host keys and `/etc/gitlab/gitlab-secrets.json` files should be
|
|||
identical on all nodes. Check this by running the following on all nodes and
|
||||
comparing the output:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo sha256sum /etc/ssh/ssh_host* /etc/gitlab/gitlab-secrets.json
|
||||
```
|
||||
|
||||
|
@ -136,7 +136,7 @@ access to the **primary** node during the maintenance window.
|
|||
|
||||
For instance, you might run the following commands on the server(s) making up your **primary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
|
||||
sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
|
||||
sudo iptables -A INPUT --destination-port 22 -j REJECT
|
||||
|
|
|
@ -30,7 +30,7 @@ they must be manually replicated to the **secondary** node.
|
|||
|
||||
1. SSH into the **primary** node, and execute the command below:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo cat /etc/gitlab/gitlab-secrets.json
|
||||
```
|
||||
|
||||
|
@ -38,20 +38,20 @@ they must be manually replicated to the **secondary** node.
|
|||
|
||||
1. SSH into the **secondary** node and login as the `root` user:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Make a backup of any existing secrets:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
|
||||
```
|
||||
|
||||
1. Copy `/etc/gitlab/gitlab-secrets.json` from the **primary** node to the **secondary** node, or
|
||||
copy-and-paste the file contents between nodes:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab-secrets.json
|
||||
|
||||
# paste the output of the `cat` command you ran on the primary
|
||||
|
@ -60,14 +60,14 @@ they must be manually replicated to the **secondary** node.
|
|||
|
||||
1. Ensure the file permissions are correct:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
chown root:root /etc/gitlab/gitlab-secrets.json
|
||||
chmod 0600 /etc/gitlab/gitlab-secrets.json
|
||||
```
|
||||
|
||||
1. Reconfigure the **secondary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
gitlab-ctl restart
|
||||
```
|
||||
|
@ -88,13 +88,13 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
1. SSH into the **secondary** node and login as the `root` user:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Make a backup of any existing SSH host keys:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
|
||||
```
|
||||
|
||||
|
@ -102,14 +102,14 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
If you can access your **primary** node using the **root** user:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
|
||||
scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
|
||||
```
|
||||
|
||||
If you only have access through a user with **sudo** privileges:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# Run this from your primary node:
|
||||
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
|
||||
|
||||
|
@ -120,20 +120,20 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
1. On your **secondary** node, ensure the file permissions are correct:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
chown root:root /etc/ssh/ssh_host_*_key*
|
||||
chmod 0600 /etc/ssh/ssh_host_*_key*
|
||||
```
|
||||
|
||||
1. To verify key fingerprint matches, execute the following command on both nodes:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
|
||||
```
|
||||
|
||||
You should get an output similar to this one and they should be identical on both nodes:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
|
||||
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
|
||||
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
|
||||
|
@ -142,7 +142,7 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
1. Verify that you have the correct public keys for the existing private keys:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# This will print the fingerprint for private keys:
|
||||
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
|
||||
|
||||
|
@ -155,7 +155,7 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
1. Restart sshd on your **secondary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# Debian or Ubuntu installations
|
||||
sudo service ssh reload
|
||||
|
||||
|
@ -167,7 +167,7 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
1. SSH into your GitLab **secondary** server and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -180,7 +180,7 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
1. Reconfigure the **secondary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -201,20 +201,20 @@ keys must be manually replicated to the **secondary** node.
|
|||
1. Click the **Add node** button to add the **secondary** node.
|
||||
1. SSH into your GitLab **secondary** server and restart the services:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl restart
|
||||
```
|
||||
|
||||
Check if there are any common issue with your Geo setup by running:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
1. SSH into your **primary** server and login as root to verify the
|
||||
**secondary** node is reachable or there are any common issue with your Geo setup:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. SSH into your GitLab **primary** server and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -62,13 +62,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. Reconfigure the **primary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Execute the command below to define the node as **primary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl set-geo-primary-node
|
||||
```
|
||||
|
||||
|
@ -78,7 +78,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
Generate a MD5 hash of the desired password:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl pg-password-md5 gitlab
|
||||
# Enter password: <your_password_here>
|
||||
# Confirm password: <your_password_here>
|
||||
|
@ -101,7 +101,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
called `gitlab_replicator`. You must set the password for this user manually.
|
||||
You will be prompted to enter a password:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl set-replication-password
|
||||
```
|
||||
|
||||
|
@ -134,7 +134,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
To lookup the address of a Geo node, SSH in to the Geo node and execute:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
##
|
||||
## Private address
|
||||
##
|
||||
|
@ -219,13 +219,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
1. Save the file and reconfigure GitLab for the database listen changes and
|
||||
the replication slot changes to be applied:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
Restart PostgreSQL for its changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl restart postgresql
|
||||
```
|
||||
|
||||
|
@ -240,7 +240,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
Save the file and reconfigure GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -254,7 +254,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
the **secondary** node needs a copy of the certificate. Make a copy of the PostgreSQL
|
||||
`server.crt` file on the **primary** node by running this command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cat ~gitlab-psql/data/server.crt
|
||||
```
|
||||
|
||||
|
@ -266,13 +266,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. SSH into your GitLab **secondary** server and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Stop application server and Sidekiq
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl stop unicorn
|
||||
gitlab-ctl stop sidekiq
|
||||
```
|
||||
|
@ -282,7 +282,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. [Check TCP connectivity][rake-maintenance] to the **primary** node's PostgreSQL server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake gitlab:tcp_check[<primary_node_ip>,5432]
|
||||
```
|
||||
|
||||
|
@ -295,7 +295,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. Create a file `server.crt` in the **secondary** server, with the content you got on the last step of the **primary** node's setup:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
editor server.crt
|
||||
```
|
||||
|
||||
|
@ -303,7 +303,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
Install the `server.crt` file:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
install \
|
||||
-D \
|
||||
-o gitlab-psql \
|
||||
|
@ -319,7 +319,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
1. Test that the `gitlab-psql` user can connect to the **primary** node's database
|
||||
(the default Omnibus database name is gitlabhq_production):
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo \
|
||||
-u gitlab-psql /opt/gitlab/embedded/bin/psql \
|
||||
--list \
|
||||
|
@ -377,13 +377,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
|
||||
1. Reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Restart PostgreSQL for the IP change to take effect and reconfigure again:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl restart postgresql
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
@ -405,7 +405,7 @@ data before running `pg_basebackup`.
|
|||
|
||||
1. SSH into your GitLab **secondary** server and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -419,7 +419,7 @@ data before running `pg_basebackup`.
|
|||
CAUTION: **Warning:** Each Geo **secondary** node must have its own unique replication slot name.
|
||||
Using the same slot name between two secondaries will break PostgreSQL replication.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl replicate-geo-database \
|
||||
--slot-name=<secondary_node_name> \
|
||||
--host=<primary_node_ip>
|
||||
|
@ -471,7 +471,7 @@ work:
|
|||
admin user. If you are using an Omnibus-managed database, log onto the **primary**
|
||||
node that is running the PostgreSQL database (the default Omnibus database name is gitlabhq_production):
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo \
|
||||
-u gitlab-psql /opt/gitlab/embedded/bin/psql \
|
||||
-h /var/opt/gitlab/postgresql gitlabhq_production
|
||||
|
@ -501,7 +501,7 @@ work:
|
|||
|
||||
1. Save the file and reconfigure GitLab for the changes to be applied:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ We need to make Docker Registry send notification events to the
|
|||
|
||||
1. SSH into your GitLab **primary** server and login as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -70,7 +70,7 @@ We need to make Docker Registry send notification events to the
|
|||
|
||||
1. Reconfigure the **primary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -90,7 +90,7 @@ generate a short-lived JWT that is pull-only-capable to access the
|
|||
|
||||
1. SSH into the **secondary** node and login as the `root` user:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -105,7 +105,7 @@ generate a short-lived JWT that is pull-only-capable to access the
|
|||
|
||||
1. Reconfigure the **secondary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
|
|
@ -13,13 +13,13 @@ developed and tested. We aim to be compatible with most external
|
|||
|
||||
1. SSH into a GitLab **primary** application server and login as root:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Execute the command below to define the node as **primary** node:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-ctl set-geo-primary-node
|
||||
```
|
||||
|
||||
|
@ -100,7 +100,7 @@ To configure the connection to the external read-replica database and enable Log
|
|||
|
||||
1. SSH into a GitLab **secondary** application server and login as root:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -147,7 +147,7 @@ the tracking database on port 5432.
|
|||
|
||||
1. SSH into a GitLab **secondary** server and login as root:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -168,7 +168,7 @@ the tracking database on port 5432.
|
|||
|
||||
1. Run the tracking database migrations:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake geo:db:create
|
||||
gitlab-rake geo:db:migrate
|
||||
```
|
||||
|
@ -179,7 +179,7 @@ the tracking database on port 5432.
|
|||
Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection
|
||||
params to match your environment. Execute it to set up the FDW connection.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
#!/bin/bash
|
||||
|
||||
# Secondary Database connection params:
|
||||
|
@ -213,6 +213,6 @@ the tracking database on port 5432.
|
|||
1. Save the file and [restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart)
|
||||
1. Populate the FDW tables:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake geo:db:refresh_foreign_tables
|
||||
```
|
||||
|
|
|
@ -128,7 +128,7 @@ the **primary** database. Use the following as a guide.
|
|||
|
||||
Note that the username (`gitlab` by default) is incorporated into the hash.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl pg-password-md5 gitlab
|
||||
# Enter password: <your_password_here>
|
||||
# Confirm password: <your_password_here>
|
||||
|
@ -187,7 +187,7 @@ Configure the tracking database.
|
|||
Note that the username (`gitlab_geo` by default) is incorporated into the
|
||||
hash.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl pg-password-md5 gitlab_geo
|
||||
# Enter password: <your_password_here>
|
||||
# Confirm password: <your_password_here>
|
||||
|
|
|
@ -10,13 +10,13 @@ Once removed from the Geo admin page, you must stop and uninstall the **secondar
|
|||
|
||||
1. On the **secondary** node, stop GitLab:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-ctl stop
|
||||
```
|
||||
|
||||
1. On the **secondary** node, uninstall GitLab:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Stop gitlab and remove its supervision process
|
||||
sudo gitlab-ctl uninstall
|
||||
|
||||
|
@ -31,7 +31,7 @@ Once GitLab has been uninstalled from the **secondary** node, the replication sl
|
|||
|
||||
1. On the **primary** node, start a PostgreSQL console session:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-psql
|
||||
```
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ health check manually to get this information as well as a few more details.
|
|||
This rake task can be run on an app node in the **primary** or **secondary**
|
||||
Geo nodes:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
|
@ -73,7 +73,7 @@ Checking Geo ... Finished
|
|||
Current sync information can be found manually by running this rake task on any
|
||||
**secondary** app node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake geo:status
|
||||
```
|
||||
|
||||
|
@ -127,7 +127,7 @@ This name is used to look up the node with the same **Name** in
|
|||
To check if the current machine has a node name that matches a node in the
|
||||
database, run the check task:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
|
@ -151,7 +151,7 @@ This machine's Geo node name matches a database record ... no
|
|||
|
||||
When running this rake task, you may see errors if the nodes are not properly configured:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
|
@ -279,7 +279,7 @@ and indicates that your initial dataset is too large to be replicated in the def
|
|||
Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
|
||||
`--backup-timeout`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl \
|
||||
replicate-geo-database \
|
||||
--host=<primary_node_hostname> \
|
||||
|
@ -297,7 +297,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
|
|||
|
||||
1. Start a PostgreSQL console session:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-psql
|
||||
```
|
||||
|
||||
|
@ -348,7 +348,7 @@ postgresql['hot_standby_feedback'] = 'on'
|
|||
|
||||
Then reconfigure GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -370,7 +370,7 @@ gitlab_rails['gitlab_shell_git_timeout'] = 10800
|
|||
|
||||
Then reconfigure GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -390,7 +390,7 @@ to start again from scratch, there are a few steps that can help you:
|
|||
You need to send a **SIGTSTP** kill signal for the first phase and them a **SIGTERM**
|
||||
when all jobs have finished. Otherwise just use the `gitlab-ctl stop` commands.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl status sidekiq
|
||||
# run: sidekiq: (pid 10180) <- this is the PID you will use
|
||||
kill -TSTP 10180 # change to the correct PID
|
||||
|
@ -401,13 +401,13 @@ to start again from scratch, there are a few steps that can help you:
|
|||
|
||||
You can watch Sidekiq logs to know when Sidekiq jobs processing have finished:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl tail sidekiq
|
||||
```
|
||||
|
||||
1. Rename repository storage folders and create new ones. If you are not concerned about possible orphaned directories and files, then you can simply skip this step.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mv /var/opt/gitlab/git-data/repositories /var/opt/gitlab/git-data/repositories.old
|
||||
mkdir -p /var/opt/gitlab/git-data/repositories
|
||||
chown git:git /var/opt/gitlab/git-data/repositories
|
||||
|
@ -432,7 +432,7 @@ to start again from scratch, there are a few steps that can help you:
|
|||
|
||||
To rename all of them:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl stop
|
||||
|
||||
mv /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared.old
|
||||
|
@ -447,13 +447,13 @@ to start again from scratch, there are a few steps that can help you:
|
|||
Reconfigure in order to recreate the folders and make sure permissions and ownership
|
||||
are correctly
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Reset the Tracking Database
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake geo:db:drop
|
||||
gitlab-ctl reconfigure
|
||||
gitlab-rake geo:db:setup
|
||||
|
@ -461,7 +461,7 @@ to start again from scratch, there are a few steps that can help you:
|
|||
|
||||
1. Restart previously stopped services
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl start
|
||||
```
|
||||
|
||||
|
@ -537,7 +537,7 @@ To check the configuration:
|
|||
|
||||
1. SSH into an app node in the **secondary**:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
|
@ -552,14 +552,14 @@ To check the configuration:
|
|||
|
||||
If the tracking database is running on the same node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-geo-psql
|
||||
```
|
||||
|
||||
Or, if the tracking database is running on a different node, you must specify
|
||||
the user and host when entering the database console:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-geo-psql -U gitlab_geo -h <IP of tracking database>
|
||||
```
|
||||
|
||||
|
@ -646,7 +646,7 @@ To check the configuration:
|
|||
|
||||
Make sure the password is correct. You can test that logins work by running `psql`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# Connect to the tracking database as the `gitlab_geo` user
|
||||
sudo \
|
||||
-u git /opt/gitlab/embedded/bin/psql \
|
||||
|
@ -685,7 +685,7 @@ reload of the FDW schema. To manually reload the FDW schema:
|
|||
1. On the node running the Geo tracking database, enter the PostgreSQL console via
|
||||
the `gitlab_geo` user:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo \
|
||||
-u git /opt/gitlab/embedded/bin/psql \
|
||||
-h /var/opt/gitlab/geo-postgresql \
|
||||
|
@ -729,7 +729,7 @@ Geo database has an outdated FDW remote schema. It contains 229 of 236 expected
|
|||
|
||||
To resolve this, run the following command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake geo:db:refresh_foreign_tables
|
||||
```
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ everything is working correctly:
|
|||
|
||||
1. Run the Geo raketask on all nodes, everything should be green:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS)
|
|||
|
||||
Example of the output you will see when pushing to a **secondary** node:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
$ git push
|
||||
remote:
|
||||
remote: You're pushing to a Geo secondary. We'll help you by proxying this
|
||||
|
|
|
@ -16,7 +16,7 @@ This update will occur even if major PostgreSQL updates are disabled.
|
|||
Before [refreshing Foreign Data Wrapper during a Geo HA upgrade](https://docs.gitlab.com/omnibus/update/README.html#run-post-deployment-migrations-and-checks),
|
||||
restart the Geo tracking database:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl restart geo-postgresql
|
||||
```
|
||||
|
||||
|
@ -31,7 +31,7 @@ for the recommended procedure.
|
|||
|
||||
This can be temporarily disabled by running the following before updating:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo touch /etc/gitlab/disable-postgresql-upgrade
|
||||
```
|
||||
|
||||
|
@ -41,7 +41,7 @@ Before 10.8, broadcast messages would not propagate without flushing
|
|||
the cache on the **secondary** nodes. This has been fixed in 10.8, but
|
||||
requires one last cache flush on each **secondary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake cache:clear
|
||||
```
|
||||
|
||||
|
@ -55,7 +55,7 @@ authentication method.
|
|||
|
||||
1. **(primary)** Login to your **primary** node and run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl pg-password-md5 gitlab
|
||||
# Enter password: <your_password_here>
|
||||
# Confirm password: <your_password_here>
|
||||
|
@ -82,7 +82,7 @@ authentication method.
|
|||
|
||||
1. **(primary)** Reconfigure and restart:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
sudo gitlab-ctl restart
|
||||
```
|
||||
|
@ -113,7 +113,7 @@ authentication method.
|
|||
|
||||
1. **(secondary)** Reconfigure and restart:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
sudo gitlab-ctl restart
|
||||
```
|
||||
|
@ -129,7 +129,7 @@ contents of `/etc/gitlab/gitlab-secrets.json` on each **secondary** node with th
|
|||
contents of `/etc/gitlab/gitlab-secrets.json` on the **primary** node, then run the
|
||||
following command on each **secondary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -228,7 +228,7 @@ following to clean this up.
|
|||
|
||||
On the **secondary** Geo nodes, run as root:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mv /var/opt/gitlab/gitlab-rails/working /var/opt/gitlab/gitlab-rails/working.old
|
||||
mkdir /var/opt/gitlab/gitlab-rails/working
|
||||
chmod 700 /var/opt/gitlab/gitlab-rails/working
|
||||
|
@ -240,7 +240,7 @@ You may delete `/var/opt/gitlab/gitlab-rails/working.old` any time.
|
|||
Once this is done, we advise restarting GitLab on the **secondary** nodes for the
|
||||
new working directory to be used:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl restart
|
||||
```
|
||||
|
||||
|
@ -289,7 +289,7 @@ is prepended with the relevant node for better clarity:
|
|||
1. **(secondary)** Make a backup of the `recovery.conf` file on **all**
|
||||
**secondary** nodes to preserve PostgreSQL's credentials:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo cp /var/opt/gitlab/postgresql/data/recovery.conf /var/opt/gitlab/
|
||||
```
|
||||
|
||||
|
@ -301,7 +301,7 @@ is prepended with the relevant node for better clarity:
|
|||
stop all services except `postgresql` as we will use it to re-initialize the
|
||||
**secondary** node's database:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl stop
|
||||
sudo gitlab-ctl start postgresql
|
||||
```
|
||||
|
@ -310,19 +310,19 @@ is prepended with the relevant node for better clarity:
|
|||
|
||||
1. **(secondary)** Stop all services:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl stop
|
||||
```
|
||||
|
||||
1. **(secondary)** Prevent running database migrations:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo touch /etc/gitlab/skip-auto-migrations
|
||||
```
|
||||
|
||||
1. **(secondary)** Move the old database to another directory:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo mv /var/opt/gitlab/postgresql{,.bak}
|
||||
```
|
||||
|
||||
|
@ -331,33 +331,33 @@ is prepended with the relevant node for better clarity:
|
|||
|
||||
1. **(secondary)** Make sure all services are up:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl start
|
||||
```
|
||||
|
||||
1. **(secondary)** Reconfigure GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. **(secondary)** Run the PostgreSQL upgrade command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl pg-upgrade
|
||||
```
|
||||
|
||||
1. **(secondary)** See the stored credentials for the database that you will
|
||||
need to re-initialize the replication:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo grep -s primary_conninfo /var/opt/gitlab/recovery.conf
|
||||
```
|
||||
|
||||
1. **(secondary)** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the
|
||||
embedded paths if necessary:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
#!/bin/bash
|
||||
|
||||
PORT="5432"
|
||||
|
@ -404,19 +404,19 @@ is prepended with the relevant node for better clarity:
|
|||
1. **(secondary)** Run the recovery script using the credentials from the
|
||||
previous step:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo bash /tmp/replica.sh
|
||||
```
|
||||
|
||||
1. **(secondary)** Reconfigure GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. **(secondary)** Start all services:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl start
|
||||
```
|
||||
|
||||
|
@ -425,7 +425,7 @@ is prepended with the relevant node for better clarity:
|
|||
1. **(primary)** After all **secondary** nodes are updated, start all services in
|
||||
**primary** node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl start
|
||||
```
|
||||
|
||||
|
@ -437,7 +437,7 @@ and it is required since 10.0.
|
|||
|
||||
1. Run database migrations on tracking database:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake geo:db:migrate
|
||||
```
|
||||
|
||||
|
|
|
@ -96,7 +96,7 @@ one is located in `config.yml` of GitLab Shell.
|
|||
Here is an example workflow of uploading a very large file and then checking it
|
||||
into your Git repository:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git clone git@example.com:group/project.git
|
||||
|
||||
git annex init 'My Laptop' # initialize the annex project and give an optional description
|
||||
|
@ -165,7 +165,7 @@ repository.
|
|||
|
||||
Downloading a single large file is also very simple:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git clone git@gitlab.example.com:group/project.git
|
||||
|
||||
git annex sync # sync Git branches but not the large file
|
||||
|
@ -174,7 +174,7 @@ git annex get debian.iso # download the large file
|
|||
|
||||
To download all files:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git clone git@gitlab.example.com:group/project.git
|
||||
|
||||
git annex sync --content # sync Git branches and download all the large files
|
||||
|
|
|
@ -45,7 +45,7 @@ AcceptEnv GIT_PROTOCOL
|
|||
|
||||
Once configured, restart the SSH daemon. In Ubuntu, run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo service ssh restart
|
||||
```
|
||||
|
||||
|
@ -54,7 +54,7 @@ sudo service ssh restart
|
|||
In order to use the new protocol, clients need to either pass the configuration
|
||||
`-c protocol.version=2` to the Git command, or set it globally:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
git config --global protocol.version 2
|
||||
```
|
||||
|
||||
|
@ -62,7 +62,7 @@ git config --global protocol.version 2
|
|||
|
||||
Verify Git v2 is used by the client:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
GIT_TRACE_CURL=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | grep Git-Protocol
|
||||
```
|
||||
|
||||
|
@ -74,13 +74,13 @@ You should see that the `Git-Protocol` header is sent:
|
|||
|
||||
Verify Git v2 is used by the server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | head
|
||||
```
|
||||
|
||||
Example response using Git protocol v2:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
$ GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | head
|
||||
10:42:50.574485 pkt-line.c:80 packet: git< # service=git-upload-pack
|
||||
10:42:50.574653 pkt-line.c:80 packet: git< 0000
|
||||
|
@ -98,7 +98,7 @@ $ GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-ins
|
|||
|
||||
Verify Git v2 is used by the client:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
GIT_SSH_COMMAND="ssh -v" git -c protocol.version=2 ls-remote ssh://your-gitlab-instance.com:group/repo.git 2>&1 |grep GIT_PROTOCOL
|
||||
```
|
||||
|
||||
|
|
|
@ -309,7 +309,7 @@ can read and write to `/mnt/gitlab/storage2`.
|
|||
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
|
||||
1. Tail the logs to see the requests:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl tail gitaly
|
||||
```
|
||||
|
||||
|
@ -343,7 +343,7 @@ can read and write to `/mnt/gitlab/storage2`.
|
|||
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
|
||||
1. Tail the logs to see the requests:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
tail -f /home/git/gitlab/log/gitaly.log
|
||||
```
|
||||
|
||||
|
@ -435,7 +435,7 @@ To configure Gitaly with TLS:
|
|||
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on client node(s).
|
||||
1. On the Gitaly server, create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo mkdir -p /etc/gitlab/ssl
|
||||
sudo chmod 755 /etc/gitlab/ssl
|
||||
sudo cp key.pem cert.pem /etc/gitlab/ssl/
|
||||
|
@ -491,7 +491,7 @@ To configure Gitaly with TLS:
|
|||
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) on client node(s).
|
||||
1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo mkdir -p /etc/gitlab/ssl
|
||||
sudo chmod 700 /etc/gitlab/ssl
|
||||
sudo cp key.pem cert.pem /etc/gitlab/ssl/
|
||||
|
@ -856,7 +856,7 @@ your GitLab / Gitaly server already at `/opt/gitlab/embedded/bin/gitaly-debug`.
|
|||
If you're investigating an older GitLab version you can compile this
|
||||
tool offline and copy the executable to your server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
git clone https://gitlab.com/gitlab-org/gitaly.git
|
||||
cd cmd/gitaly-debug
|
||||
GOOS=linux GOARCH=amd64 go build -o gitaly-debug
|
||||
|
@ -864,7 +864,7 @@ GOOS=linux GOARCH=amd64 go build -o gitaly-debug
|
|||
|
||||
To see the help page of `gitaly-debug` for a list of supported sub-commands, run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitaly-debug -h
|
||||
```
|
||||
|
||||
|
@ -887,7 +887,7 @@ default level is `WARN`.
|
|||
|
||||
You can run a GRPC trace with:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
GRPC_TRACE=all GRPC_VERBOSITY=DEBUG sudo gitlab-rake gitlab:gitaly:check
|
||||
```
|
||||
|
||||
|
@ -925,7 +925,7 @@ Confirm the following are all true:
|
|||
- When any user performs a `git push` to any repository on this Gitaly node, it
|
||||
fails with the following error (note the `401 Unauthorized`):
|
||||
|
||||
```sh
|
||||
```shell
|
||||
remote: GitLab: 401 Unauthorized
|
||||
To <REMOTE_URL>
|
||||
! [remote rejected] branch-name -> branch-name (pre-receive hook declined)
|
||||
|
@ -939,7 +939,7 @@ Confirm the following are all true:
|
|||
- When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors
|
||||
when reaching the `/api/v4/internal/allowed` endpoint:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# api_json.log
|
||||
{
|
||||
"time": "2019-07-18T00:30:14.967Z",
|
||||
|
@ -1009,7 +1009,7 @@ If you are having trouble connecting to a Gitaly node with command line (CLI) to
|
|||
|
||||
Verify that you can reach Gitaly via TCP:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]
|
||||
```
|
||||
|
||||
|
@ -1019,7 +1019,7 @@ If you use proxy servers in your command line environment, such as Bash, these c
|
|||
|
||||
If you use Bash or a compatible command line environment, run the following commands to determine whether you have proxy servers configured:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
echo $http_proxy
|
||||
echo $https_proxy
|
||||
```
|
||||
|
@ -1028,7 +1028,7 @@ If either of these variables have a value, your Gitaly CLI connections may be ge
|
|||
|
||||
To remove the proxy setting, run the following commands (depending on which variables had values):
|
||||
|
||||
```bash
|
||||
```shell
|
||||
unset http_proxy
|
||||
unset https_proxy
|
||||
```
|
||||
|
|
|
@ -58,7 +58,7 @@ On each Consul node perform the following:
|
|||
Before moving on, make sure Consul is configured correctly. Run the following
|
||||
command to verify all server nodes are communicating:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
/opt/gitlab/embedded/bin/consul members
|
||||
```
|
||||
|
||||
|
|
|
@ -46,7 +46,7 @@ deploy the bundled PostgreSQL.
|
|||
and confirmation. Use the value that is output by this command in the next
|
||||
step as the value of `POSTGRESQL_PASSWORD_HASH`.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl pg-password-md5 gitlab
|
||||
```
|
||||
|
||||
|
@ -202,7 +202,7 @@ When using default setup, minimum configuration requires:
|
|||
- `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair.
|
||||
Can be generated with:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME
|
||||
```
|
||||
|
||||
|
@ -245,7 +245,7 @@ We will need the following password information for the application's database u
|
|||
- `POSTGRESQL_PASSWORD_HASH`. This is a hash generated out of the username/password pair.
|
||||
Can be generated with:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl pg-password-md5 POSTGRESQL_USERNAME
|
||||
```
|
||||
|
||||
|
@ -258,7 +258,7 @@ When using default setup, minimum configuration requires:
|
|||
- `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of PgBouncer username/password pair.
|
||||
Can be generated with:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl pg-password-md5 PGBOUNCER_USERNAME
|
||||
```
|
||||
|
||||
|
@ -376,13 +376,13 @@ Select one node as a primary node.
|
|||
|
||||
1. Open a database prompt:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-psql -d gitlabhq_production
|
||||
```
|
||||
|
||||
1. Enable the `pg_trgm` extension:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
CREATE EXTENSION pg_trgm;
|
||||
```
|
||||
|
||||
|
@ -390,7 +390,7 @@ Select one node as a primary node.
|
|||
|
||||
1. Verify the cluster is initialized with one node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr cluster show
|
||||
```
|
||||
|
||||
|
@ -411,7 +411,7 @@ Select one node as a primary node.
|
|||
|
||||
1. Set up the repmgr standby:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby setup MASTER_NODE_NAME
|
||||
```
|
||||
|
||||
|
@ -436,7 +436,7 @@ Select one node as a primary node.
|
|||
|
||||
1. Verify the node now appears in the cluster:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr cluster show
|
||||
```
|
||||
|
||||
|
@ -457,7 +457,7 @@ Before moving on, make sure the databases are configured correctly. Run the
|
|||
following command on the **primary** node to verify that replication is working
|
||||
properly:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr cluster show
|
||||
```
|
||||
|
||||
|
@ -475,7 +475,7 @@ If the 'Role' column for any node says "FAILED", check the
|
|||
|
||||
Also, check that the check master command works successfully on each node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
su - gitlab-consul
|
||||
gitlab-ctl repmgr-check-master || echo 'This node is a standby repmgr node'
|
||||
```
|
||||
|
@ -512,7 +512,7 @@ attributes set, but the following need to be set.
|
|||
|
||||
Ensure that all migrations ran:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake gitlab:db:configure
|
||||
```
|
||||
|
||||
|
@ -702,7 +702,7 @@ After deploying the configuration follow these steps:
|
|||
|
||||
Enable the `pg_trgm` extension
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-psql -d gitlabhq_production
|
||||
```
|
||||
|
||||
|
@ -714,7 +714,7 @@ After deploying the configuration follow these steps:
|
|||
|
||||
Make this node a standby of the primary
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby setup 10.6.0.21
|
||||
```
|
||||
|
||||
|
@ -722,7 +722,7 @@ After deploying the configuration follow these steps:
|
|||
|
||||
Make this node a standby of the primary
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby setup 10.6.0.21
|
||||
```
|
||||
|
||||
|
@ -730,13 +730,13 @@ After deploying the configuration follow these steps:
|
|||
|
||||
Set `gitlab-consul` user's PgBouncer password to `toomanysecrets`
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
|
||||
```
|
||||
|
||||
Run database migrations
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-rake gitlab:db:configure
|
||||
```
|
||||
|
||||
|
@ -863,7 +863,7 @@ If you need to failover manually, you have two options:
|
|||
|
||||
Run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl stop postgresql
|
||||
```
|
||||
|
||||
|
@ -875,14 +875,14 @@ standby nodes.
|
|||
1. Ensure the old master node is not still active.
|
||||
1. Login to the server that should become the new master and run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby promote
|
||||
```
|
||||
|
||||
1. If there are any other standby servers in the cluster, have them follow
|
||||
the new master server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby follow NEW_MASTER
|
||||
```
|
||||
|
||||
|
@ -894,7 +894,7 @@ after it has been restored to service.
|
|||
- If you want to remove the node from the cluster, on any other node in the
|
||||
cluster, run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby unregister --node=X
|
||||
```
|
||||
|
||||
|
@ -902,7 +902,7 @@ after it has been restored to service.
|
|||
|
||||
To find this, you can use:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
awk -F = '$1 == "node" { print $2 }' /var/opt/gitlab/postgresql/repmgr.conf
|
||||
```
|
||||
|
||||
|
@ -914,13 +914,13 @@ after it has been restored to service.
|
|||
|
||||
Then you will use this id to unregister the node:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby unregister --node=959789412
|
||||
```
|
||||
|
||||
- To add the node as a standby server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl repmgr standby follow NEW_MASTER
|
||||
gitlab-ctl restart repmgrd
|
||||
```
|
||||
|
@ -972,7 +972,7 @@ the previous section:
|
|||
1. On the current master node, create a password for the `gitlab` and
|
||||
`gitlab_repmgr` user:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-psql -d template1
|
||||
template1=# \password gitlab_repmgr
|
||||
Enter password: ****
|
||||
|
@ -992,7 +992,7 @@ the previous section:
|
|||
1. Create a `.pgpass` file. Enter the `gitlab_repmgr` password twice to
|
||||
when asked:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl write-pgpass --user gitlab_repmgr --hostuser gitlab-psql --database '*'
|
||||
```
|
||||
|
||||
|
|
|
@ -101,7 +101,7 @@ these additional steps before proceeding with GitLab installation.
|
|||
|
||||
On the first application server, run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ NOTE: **Note:** From GitLab 12.1, it will automatically be detected if Rugged ca
|
|||
|
||||
If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:features:unset_rugged
|
||||
```
|
||||
|
||||
|
@ -82,7 +82,7 @@ on an Linux NFS server, do the following:
|
|||
|
||||
1. On the NFS server, run:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
echo 0 > /proc/sys/fs/leases-enable
|
||||
sysctl -w fs.leases-enable=0
|
||||
```
|
||||
|
@ -186,7 +186,7 @@ single NFS mount point as you normally would in `/etc/fstab`. Let's assume your
|
|||
NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in
|
||||
`/etc/fstab`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
/gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
|
||||
/gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
|
||||
/gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0
|
||||
|
|
|
@ -27,7 +27,7 @@ Using EFS may negatively impact performance. Please review the [relevant documen
|
|||
|
||||
Installing the nfs-kernel-server package allows you to share directories with the clients running the GitLab application.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
apt-get update
|
||||
apt-get install nfs-kernel-server
|
||||
```
|
||||
|
@ -47,7 +47,7 @@ In this setup we will share the home directory on the host with the client. Edit
|
|||
Restart the NFS server after making changes to the `exports` file for the changes
|
||||
to take effect.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
systemctl restart nfs-kernel-server
|
||||
```
|
||||
|
||||
|
@ -64,7 +64,7 @@ inside your HA environment to the NFS server configured above.
|
|||
The nfs-common provides NFS functionality without installing server components which
|
||||
we don't need running on the application nodes.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
apt-get update
|
||||
apt-get install nfs-common
|
||||
```
|
||||
|
@ -76,14 +76,14 @@ Please note that if your mount point directory contains any files they will be h
|
|||
once the remote shares are mounted. An empty/new directory on the client is recommended
|
||||
for this purpose.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mkdir -p /nfs/home
|
||||
```
|
||||
|
||||
Confirm that the mount point works by mounting it on the client and checking that
|
||||
it is mounted with the command below:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mount <host_ip_address>:/home
|
||||
df -h
|
||||
```
|
||||
|
@ -134,7 +134,7 @@ Check that NFS traffic from the client is allowed by the firewall on the host by
|
|||
the command: `sudo ufw status`. If it's being blocked, then you can allow traffic from a specific
|
||||
client with the command below.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo ufw allow from <client-ip-address> to any port nfs
|
||||
```
|
||||
|
||||
|
|
|
@ -57,7 +57,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
|
|||
1. Create a `.pgpass` file so Consul is able to
|
||||
reload PgBouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
|
||||
```
|
||||
|
||||
|
@ -65,7 +65,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
|
|||
|
||||
1. Ensure each node is talking to the current master:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
|
||||
```
|
||||
|
||||
|
@ -77,7 +77,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
|
|||
|
||||
1. Once the console prompt is available, run the following queries:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
show databases ; show clients ;
|
||||
```
|
||||
|
||||
|
|
|
@ -8,8 +8,10 @@ type: reference
|
|||
|
||||
The following are the requirements for providing your own Redis instance:
|
||||
|
||||
- Redis version 2.8 or higher. Version 3.2 or higher is recommend as this is
|
||||
what ships with the GitLab Omnibus package.
|
||||
- GitLab 12.0 and later requires Redis version 3.2 or higher. Version 3.2 or higher is recommend as this is
|
||||
what ships with the GitLab Omnibus package. Older Redis versions do not
|
||||
support an optional count argument to SPOP which is now required for
|
||||
[Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
|
||||
- Standalone Redis or Redis high availability with Sentinel are supported. Redis
|
||||
Cluster is not supported.
|
||||
- Managed Redis from cloud providers such as AWS Elasticache will work. If these
|
||||
|
@ -978,7 +980,7 @@ To make sure your configuration is correct:
|
|||
|
||||
1. To simulate a failover on master Redis, SSH into the Redis server and run:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# port must match your master redis port, and the sleep time must be a few seconds bigger than defined one
|
||||
redis-cli -h localhost -p 6379 DEBUG sleep 20
|
||||
```
|
||||
|
|
|
@ -102,14 +102,14 @@ for a real-world example of this exploit.
|
|||
|
||||
1. Reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
sudo gitlab-ctl restart
|
||||
```
|
||||
|
||||
1. Verify that everything is configured correctly:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:incoming_email:check
|
||||
```
|
||||
|
||||
|
@ -119,7 +119,7 @@ Reply by email should now be working.
|
|||
|
||||
1. Go to the GitLab installation directory:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
```
|
||||
|
||||
|
@ -128,20 +128,20 @@ Reply by email should now be working.
|
|||
|
||||
1. Enable `mail_room` in the init script at `/etc/default/gitlab`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo mkdir -p /etc/default
|
||||
echo 'mail_room_enabled=true' | sudo tee -a /etc/default/gitlab
|
||||
```
|
||||
|
||||
1. Restart GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo service gitlab restart
|
||||
```
|
||||
|
||||
1. Verify that everything is configured correctly:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ server that will generate the diagrams.
|
|||
|
||||
With Docker, you can just run a container like this:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
docker run -d --name plantuml -p 8080:8080 plantuml/plantuml-server:tomcat
|
||||
```
|
||||
|
||||
|
@ -50,7 +50,7 @@ own PlantUML server is easy in Debian/Ubuntu distributions using Tomcat.
|
|||
|
||||
First you need to create a `plantuml.war` file from the source code:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo apt-get install graphviz openjdk-8-jdk git-core maven
|
||||
git clone https://github.com/plantuml/plantuml-server.git
|
||||
cd plantuml-server
|
||||
|
@ -101,7 +101,7 @@ nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n rewrite ^/-/(p
|
|||
|
||||
To activate the changes, run the following command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
|
|
@ -11,6 +11,6 @@ increasing the `local_markdown_version` setting in application settings. This c
|
|||
be done by [changing the application settings through
|
||||
the API](../api/settings.md#change-application-settings):
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?local_markdown_version=<increased_number>
|
||||
```
|
||||
|
|
|
@ -156,7 +156,7 @@ _The artifacts are stored by default in
|
|||
1. Save the file and [reconfigure GitLab][] for the changes to take effect.
|
||||
1. Migrate any existing local artifacts to the object storage:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake gitlab:artifacts:migrate
|
||||
```
|
||||
|
||||
|
@ -184,7 +184,7 @@ _The artifacts are stored by default in
|
|||
1. Save the file and [restart GitLab][] for the changes to take effect.
|
||||
1. Migrate any existing local artifacts to the object storage:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -239,7 +239,7 @@ you can flip the feature flag from a Rails console.
|
|||
|
||||
1. Enter the Rails console:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rails console
|
||||
```
|
||||
|
||||
|
@ -253,7 +253,7 @@ you can flip the feature flag from a Rails console.
|
|||
|
||||
1. Enter the Rails console:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
RAILS_ENV=production sudo -u git -H bundle exec rails console
|
||||
```
|
||||
|
|
|
@ -100,7 +100,7 @@ Here is the detailed data flow:
|
|||
|
||||
The following commands are to be issued in a Rails console:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# Omnibus GitLab
|
||||
gitlab-rails console
|
||||
|
||||
|
|
|
@ -138,13 +138,13 @@ There are two ways to manually do the same thing as automatic uploading (describ
|
|||
|
||||
**Option 1: rake task**
|
||||
|
||||
```sh
|
||||
```shell
|
||||
rake gitlab:lfs:migrate
|
||||
```
|
||||
|
||||
**Option 2: rails console**
|
||||
|
||||
```sh
|
||||
```shell
|
||||
$ sudo gitlab-rails console # Login to rails console
|
||||
|
||||
> # Upload LFS files manually
|
||||
|
@ -178,7 +178,7 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`:
|
|||
1. Save the file and [reconfigure GitLab]s for the changes to take effect.
|
||||
1. Migrate any existing local LFS objects to the object storage:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake gitlab:lfs:migrate
|
||||
```
|
||||
|
||||
|
@ -214,7 +214,7 @@ For source installations the settings are nested under `lfs:` and then
|
|||
1. Save the file and [restart GitLab][] for the changes to take effect.
|
||||
1. Migrate any existing local LFS objects to the object storage:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
|
|
@ -50,7 +50,7 @@ Lets take a look at the workflow when you need to check large files into your Gi
|
|||
repository with Git LFS. For example, if you want to upload a very large file and
|
||||
check it into your Git repository:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git clone git@gitlab.example.com:group/project.git
|
||||
git lfs install # initialize the Git LFS project
|
||||
git lfs track "*.iso" # select the file extensions that you want to treat as large files
|
||||
|
@ -59,7 +59,7 @@ git lfs track "*.iso" # select the file extensions that you want
|
|||
Once a certain file extension is marked for tracking as a LFS object you can use
|
||||
Git as usual without having to redo the command to track a file with the same extension:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cp ~/tmp/debian.iso ./ # copy a large file into the current directory
|
||||
git add . # add the large file to the project
|
||||
git commit -am "Added Debian iso" # commit the file meta data
|
||||
|
@ -69,7 +69,7 @@ git push origin master # sync the git repo and large file to the
|
|||
**Make sure** that `.gitattributes` is tracked by Git. Otherwise Git
|
||||
LFS will not be working properly for people cloning the project:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git add .gitattributes
|
||||
```
|
||||
|
||||
|
@ -78,14 +78,14 @@ LFS-tracked files and clones them via HTTP. If you performed the `git clone`
|
|||
command with a SSH URL, you have to enter your GitLab credentials for HTTP
|
||||
authentication.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git clone git@gitlab.example.com:group/project.git
|
||||
```
|
||||
|
||||
If you already cloned the repository and you want to get the latest LFS object
|
||||
that are on the remote repository, eg. for a branch from origin:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs fetch origin master
|
||||
```
|
||||
|
||||
|
@ -101,14 +101,14 @@ The first thing to do before using File Locking is to tell Git LFS which
|
|||
kind of files are lockable. The following command will store PNG files
|
||||
in LFS and flag them as lockable:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs track "*.png" --lockable
|
||||
```
|
||||
|
||||
After executing the above command a file named `.gitattributes` will be
|
||||
created or updated with the following content:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
*.png filter=lfs diff=lfs merge=lfs -text lockable
|
||||
```
|
||||
|
||||
|
@ -116,7 +116,7 @@ You can also register a file type as lockable without using LFS
|
|||
(In order to be able to lock/unlock a file you need a remote server that implements the LFS File Locking API),
|
||||
in order to do that you can edit the `.gitattributes` file manually:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
*.pdf lockable
|
||||
```
|
||||
|
||||
|
@ -128,14 +128,14 @@ need to lock the file before editing it.
|
|||
|
||||
Once you're ready to edit your file you need to lock it first:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs lock images/banner.png
|
||||
Locked images/banner.png
|
||||
```
|
||||
|
||||
This will register the file as locked in your name on the server:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs locks
|
||||
images/banner.png joe ID:123
|
||||
```
|
||||
|
@ -143,13 +143,13 @@ images/banner.png joe ID:123
|
|||
Once you have pushed your changes, you can unlock the file so others can
|
||||
also edit it:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs unlock images/banner.png
|
||||
```
|
||||
|
||||
You can also unlock by id:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs unlock --id=123
|
||||
```
|
||||
|
||||
|
@ -157,7 +157,7 @@ If for some reason you need to unlock a file that was not locked by you,
|
|||
you can use the `--force` flag as long as you have a `maintainer` access on
|
||||
the project:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs unlock --id=123 --force
|
||||
```
|
||||
|
||||
|
@ -183,7 +183,7 @@ available to the project anymore. Probably the object was removed from the serve
|
|||
Git LFS will log the failures into a log file.
|
||||
To view this log file, while in project directory:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs logs last
|
||||
```
|
||||
|
||||
|
@ -215,7 +215,7 @@ This behaviour is caused by Git LFS using HTTPS connections by default when a
|
|||
|
||||
To prevent this from happening, set the lfs url in project Git config:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git config --add lfs.url "http://gitlab.example.com/group/project.git/info/lfs"
|
||||
```
|
||||
|
||||
|
@ -235,7 +235,7 @@ you use. This is described in [Git credentials man pages](https://git-scm.com/do
|
|||
For example, you can tell Git to remember the password for a period of time in
|
||||
which you expect to push the objects:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git config --global credential.helper 'cache --timeout=3600'
|
||||
```
|
||||
|
||||
|
|
|
@ -48,7 +48,7 @@ Fire up a terminal, navigate to your Git repository and:
|
|||
|
||||
1. Disable `git-annex`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git annex sync --content
|
||||
git annex direct
|
||||
git annex uninit
|
||||
|
@ -85,7 +85,7 @@ if the server also has Git Annex 6 installed. Read more in the
|
|||
|
||||
1. Backup your repository
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd repository
|
||||
git annex sync --content
|
||||
cd ..
|
||||
|
@ -97,14 +97,14 @@ if the server also has Git Annex 6 installed. Read more in the
|
|||
|
||||
1. Use `annex direct`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd repository
|
||||
git annex direct
|
||||
```
|
||||
|
||||
The output should be similar to this:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
commit
|
||||
On branch master
|
||||
Your branch is up-to-date with 'origin/master'.
|
||||
|
@ -116,13 +116,13 @@ if the server also has Git Annex 6 installed. Read more in the
|
|||
|
||||
1. Disable Git Annex with [`annex uninit`][uninit]:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git annex uninit
|
||||
```
|
||||
|
||||
The output should be similar to this:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
unannex debian.iso ok
|
||||
Deleted branch git-annex (was 2534d2c).
|
||||
```
|
||||
|
@ -131,13 +131,13 @@ if the server also has Git Annex 6 installed. Read more in the
|
|||
|
||||
1. Switch back to `indirect` mode:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git annex indirect
|
||||
```
|
||||
|
||||
The output should be similar to this:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
(merging origin/git-annex into git-annex...)
|
||||
(recording state in git...)
|
||||
commit (recording state in git...)
|
||||
|
@ -165,7 +165,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
|
|||
|
||||
1. First, make sure you have `git-lfs` installed locally:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs help
|
||||
```
|
||||
|
||||
|
@ -174,7 +174,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
|
|||
|
||||
1. Inside the repo, run the following command to initiate LFS:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs install
|
||||
```
|
||||
|
||||
|
@ -182,7 +182,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
|
|||
can track specific files, all files containing the same extension, or an
|
||||
entire directory:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git lfs track images/01.png # per file
|
||||
git lfs track **/*.png # per extension
|
||||
git lfs track images/ # per directory
|
||||
|
@ -194,7 +194,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
|
|||
|
||||
1. Add the files, commit and push them to GitLab:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git add .
|
||||
git commit -m "commit message"
|
||||
git push
|
||||
|
@ -217,7 +217,7 @@ branches created by Git Annex: `git-annex`, and all under `synced/`.
|
|||
|
||||
You can also do this on the command line with:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git branch -d synced/master
|
||||
git branch -d synced/git-annex
|
||||
git push origin :synced/master
|
||||
|
@ -229,7 +229,7 @@ git remote prune origin
|
|||
If there are still some Annex objects inside your repository (`.git/annex/`)
|
||||
or references inside `.git/config`, run `annex uninit` again:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git annex uninit
|
||||
```
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ changes.
|
|||
Finally, a restart of all GitLab processes is required for the changes to take
|
||||
effect:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# For Omnibus installations
|
||||
sudo gitlab-ctl restart
|
||||
|
||||
|
|
|
@ -133,7 +133,7 @@ After upgrading, the Grafana dashboard will be disabled and the location of your
|
|||
|
||||
To prevent the data from being relocated, you can run the following command prior to upgrading:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
echo "0" > /var/opt/gitlab/grafana/CVE_reset_status
|
||||
```
|
||||
|
||||
|
|
|
@ -110,14 +110,14 @@ buffer size is set to the same value, the default value is almost never enough.
|
|||
|
||||
To set the OS buffer size to 200 MB, on Linux you can run the following command:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sysctl -w net.core.rmem_max=209715200
|
||||
```
|
||||
|
||||
To make this permanent, add the following to `/etc/sysctl.conf` and restart the
|
||||
server:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
net.core.rmem_max=209715200
|
||||
```
|
||||
|
||||
|
@ -154,7 +154,7 @@ and password (`-password <password>`) you set earlier to the commands below._
|
|||
|
||||
Run the following command to create a database named `gitlab`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
influx -execute 'CREATE DATABASE gitlab'
|
||||
```
|
||||
|
||||
|
@ -162,7 +162,7 @@ The name **must** be `gitlab`, do not use any other name.
|
|||
|
||||
Next, make sure that the database was successfully created:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
influx -execute 'SHOW DATABASES'
|
||||
```
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ To start extra Sidekiq processes, you must enable `sidekiq-cluster`:
|
|||
|
||||
1. Save the file and reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -78,7 +78,7 @@ you list:
|
|||
|
||||
1. Save the file and reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -113,7 +113,7 @@ use all of its resources to perform those operations. To set up a separate
|
|||
|
||||
1. Save the file and reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -145,7 +145,7 @@ details.
|
|||
|
||||
1. Save the file and reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -162,7 +162,7 @@ This will set the concurrency (number of threads) for the Sidekiq process.
|
|||
|
||||
1. Save the file and reconfigure GitLab for the changes to take effect:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -207,7 +207,7 @@ For debugging purposes, you can start extra Sidekiq processes by using the comma
|
|||
`/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster`. This command
|
||||
takes arguments using the following syntax:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
|
||||
```
|
||||
|
||||
|
@ -225,14 +225,14 @@ For example, say you want to start 2 extra processes: one to process the
|
|||
`process_commit` queue, and one to process the `post_receive` queue. This can be
|
||||
done as follows:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit post_receive
|
||||
```
|
||||
|
||||
If you instead want to start one process processing both queues, you'd use the
|
||||
following syntax:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive
|
||||
```
|
||||
|
||||
|
@ -240,7 +240,7 @@ If you want to have one Sidekiq process dealing with the `process_commit` and
|
|||
`post_receive` queues, and one process to process the `gitlab_shell` queue,
|
||||
you'd use the following:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive gitlab_shell
|
||||
```
|
||||
|
||||
|
@ -272,7 +272,7 @@ The `sidekiq-cluster` command can store its PID in a file. By default no PID
|
|||
file is written, but this can be changed by passing the `--pidfile` option to
|
||||
`sidekiq-cluster`. For example:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit
|
||||
```
|
||||
|
||||
|
|
|
@ -60,7 +60,7 @@ AuthorizedKeysCommandUser git
|
|||
|
||||
Reload OpenSSH:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Debian or Ubuntu installations
|
||||
sudo service ssh reload
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ To install:
|
|||
|
||||
Then run the following:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/path/to/git-data/testfile --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
|
||||
```
|
||||
|
||||
|
@ -78,32 +78,32 @@ executed, and then read the same 1,000 files.
|
|||
[repository storage path](../repository_storage_paths.md).
|
||||
1. Create a temporary directory for the test so it's easy to remove the files later:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
mkdir test; cd test
|
||||
```
|
||||
|
||||
1. Run the command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
time for i in {0..1000}; do echo 'test' > "test${i}.txt"; done
|
||||
```
|
||||
|
||||
1. To benchmark read performance, run the command:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
time for i in {0..1000}; do cat "test${i}.txt" > /dev/null; done
|
||||
```
|
||||
|
||||
1. Remove the test files:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cd ../; rm -rf test
|
||||
```
|
||||
|
||||
The output of the `time for ...` commands will look similar to the following. The
|
||||
important metric is the `real` time.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
$ time for i in {0..1000}; do echo 'test' > "test${i}.txt"; done
|
||||
|
||||
real 0m0.116s
|
||||
|
|
|
@ -169,7 +169,7 @@ If your certificate provider provides the CA Bundle certificates, append them to
|
|||
Users should now be able to login to the Container Registry with their GitLab
|
||||
credentials using:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
docker login gitlab.example.com:4567
|
||||
```
|
||||
|
||||
|
@ -194,7 +194,7 @@ Let's assume that you want the container Registry to be accessible at
|
|||
`/etc/gitlab/ssl/registry.gitlab.example.com.key` and make sure they have
|
||||
correct permissions:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
chmod 600 /etc/gitlab/ssl/registry.gitlab.example.com.*
|
||||
```
|
||||
|
||||
|
@ -234,7 +234,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
|
|||
Users should now be able to login to the Container Registry using their GitLab
|
||||
credentials:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
docker login registry.gitlab.example.com
|
||||
```
|
||||
|
||||
|
@ -793,7 +793,7 @@ After adding the setting, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitl
|
|||
|
||||
Use curl to request debug output from the debug server:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl localhost:5001/debug/health
|
||||
curl localhost:5001/debug/vars
|
||||
```
|
||||
|
|
|
@ -166,12 +166,12 @@ The processing will be done in a background worker and requires **no downtime**.
|
|||
|
||||
For Omnibus GitLab:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rake "gitlab:packages:migrate"
|
||||
```
|
||||
|
||||
For installations from source:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:packages:migrate
|
||||
```
|
||||
|
|
|
@ -360,14 +360,14 @@ that method from working. Use the following workaround:
|
|||
|
||||
1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
|
||||
|
||||
```bash
|
||||
```shell
|
||||
printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
|
||||
echo -n | openssl s_client -connect gitlab-domain-example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
|
||||
```
|
||||
|
||||
1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-ctl restart gitlab-pages
|
||||
```
|
||||
|
||||
|
|
|
@ -98,7 +98,7 @@ The Pages daemon doesn't listen to the outside world.
|
|||
|
||||
1. Install the Pages daemon:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git
|
||||
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
|
||||
cd gitlab-pages
|
||||
|
@ -108,7 +108,7 @@ The Pages daemon doesn't listen to the outside world.
|
|||
|
||||
1. Go to the GitLab installation directory:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
```
|
||||
|
||||
|
@ -138,7 +138,7 @@ The Pages daemon doesn't listen to the outside world.
|
|||
|
||||
1. Copy the `gitlab-pages` NGINX configuration file:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
|
||||
sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf
|
||||
```
|
||||
|
@ -160,7 +160,7 @@ outside world.
|
|||
|
||||
1. Install the Pages daemon:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git
|
||||
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
|
||||
cd gitlab-pages
|
||||
|
@ -170,7 +170,7 @@ outside world.
|
|||
|
||||
1. In `gitlab.yml`, set the port to `443` and https to `true`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
## GitLab Pages
|
||||
pages:
|
||||
enabled: true
|
||||
|
@ -195,7 +195,7 @@ outside world.
|
|||
|
||||
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
|
||||
sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf
|
||||
```
|
||||
|
@ -225,7 +225,7 @@ world. Custom domains are supported, but no TLS.
|
|||
|
||||
1. Install the Pages daemon:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git
|
||||
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
|
||||
cd gitlab-pages
|
||||
|
@ -263,7 +263,7 @@ world. Custom domains are supported, but no TLS.
|
|||
|
||||
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
|
||||
sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf
|
||||
```
|
||||
|
@ -290,7 +290,7 @@ world. Custom domains and TLS are supported.
|
|||
|
||||
1. Install the Pages daemon:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git
|
||||
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
|
||||
cd gitlab-pages
|
||||
|
@ -332,7 +332,7 @@ world. Custom domains and TLS are supported.
|
|||
|
||||
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
|
||||
sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf
|
||||
```
|
||||
|
|
|
@ -85,7 +85,7 @@ You can optionally run the pseudonymizer using the following environment variabl
|
|||
- `PSEUDONYMIZER_OUTPUT_DIR` - where to store the output CSV files (defaults to `/tmp`)
|
||||
- `PSEUDONYMIZER_BATCH` - the batch size when querying the DB (defaults to `100000`)
|
||||
|
||||
```bash
|
||||
```shell
|
||||
## Omnibus
|
||||
sudo gitlab-rake gitlab:db:pseudonymizer
|
||||
|
||||
|
|
|
@ -33,13 +33,13 @@ integrity check described previously.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:git:fsck
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:git:fsck RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -58,7 +58,7 @@ Currently, integrity checks are supported for the following types of file:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:artifacts:check
|
||||
sudo gitlab-rake gitlab:lfs:check
|
||||
sudo gitlab-rake gitlab:uploads:check
|
||||
|
@ -66,7 +66,7 @@ sudo gitlab-rake gitlab:uploads:check
|
|||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:artifacts:check RAILS_ENV=production
|
||||
sudo -u git -H bundle exec rake gitlab:lfs:check RAILS_ENV=production
|
||||
sudo -u git -H bundle exec rake gitlab:uploads:check RAILS_ENV=production
|
||||
|
@ -82,7 +82,7 @@ Variable | Type | Description
|
|||
`ID_TO` | integer | Specifies the ID value to end at, inclusive of the value.
|
||||
`VERBOSE` | boolean | Causes failures to be listed individually, rather than being summarized.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:artifacts:check BATCH=100 ID_FROM=50 ID_TO=250
|
||||
sudo gitlab-rake gitlab:lfs:check BATCH=100 ID_FROM=50 ID_TO=250
|
||||
sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
|
||||
|
@ -90,7 +90,7 @@ sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
|
|||
|
||||
Example output:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
$ sudo gitlab-rake gitlab:uploads:check
|
||||
Checking integrity of Uploads
|
||||
- 1..1350: Failures: 0
|
||||
|
@ -107,7 +107,7 @@ Done!
|
|||
|
||||
Example verbose output:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
$ sudo gitlab-rake gitlab:uploads:check VERBOSE=1
|
||||
Checking integrity of Uploads
|
||||
- 1..1350: Failures: 0
|
||||
|
|
|
@ -11,13 +11,13 @@ This is equivalent of running `git repack -d` on a _bare_ repository.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake geo:git:housekeeping:incremental_repack
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake geo:git:housekeeping:incremental_repack RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -29,13 +29,13 @@ when this is enabled in GitLab.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake geo:git:housekeeping:full_repack
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake geo:git:housekeeping:full_repack RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -46,13 +46,13 @@ a reachability bitmap index when this is enabled in GitLab.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake geo:git:housekeeping:gc
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake geo:git:housekeeping:gc RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -63,12 +63,12 @@ can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake geo:run_orphaned_project_registry_cleaner
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake geo:run_orphaned_project_registry_cleaner RAILS_ENV=production
|
||||
```
|
||||
|
|
|
@ -16,7 +16,7 @@ before/after the brackets. Also, Some shells (e.g., zsh) can interpret the open/
|
|||
|
||||
To import a project from the list of your GitHub projects available:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Omnibus installations
|
||||
sudo gitlab-rake "import:github[access_token,root,foo/bar]"
|
||||
|
||||
|
@ -32,7 +32,7 @@ will get created from your GitHub project. Subgroups are also possible: `foo/foo
|
|||
|
||||
To import a specific GitHub project (named `foo/github_repo` here):
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Omnibus installations
|
||||
sudo gitlab-rake "import:github[access_token,root,foo/bar,foo/github_repo]"
|
||||
|
||||
|
|
|
@ -9,20 +9,20 @@ using the command below.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:ldap:check
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
|
||||
```
|
||||
|
||||
By default, the task will return a sample of 100 LDAP users. Change this
|
||||
limit by passing a number to the check task:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
rake gitlab:ldap:check[50]
|
||||
```
|
||||
|
||||
|
@ -41,13 +41,13 @@ instead.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:ldap:group_sync
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
bundle exec rake gitlab:ldap:group_sync
|
||||
```
|
||||
|
||||
|
@ -79,13 +79,13 @@ as the `old_provider` and the correct provider as the `new_provider`.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider]
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
bundle exec rake gitlab:ldap:rename_provider[old_provider,new_provider] RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -95,7 +95,7 @@ Consider beginning with the default server ID `main` (full provider `ldapmain`).
|
|||
If we change `main` to `mycompany`, the `new_provider` is `ldapmycompany`.
|
||||
To rename all user identities run the following command:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany]
|
||||
```
|
||||
|
||||
|
@ -116,13 +116,13 @@ for them:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:ldap:rename_provider
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -136,6 +136,6 @@ What is the new provider? Ex. 'ldapcustom': ldapmycompany
|
|||
This tasks also accepts the `force` environment variable which will skip the
|
||||
confirmation dialog:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider] force=yes
|
||||
```
|
||||
|
|
|
@ -6,13 +6,13 @@ This command gathers information about your GitLab installation and the System i
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:env:info
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
bundle exec rake gitlab:env:info RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -66,13 +66,13 @@ You may also have a look at our Troubleshooting Guides:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:check
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
bundle exec rake gitlab:check RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -129,13 +129,13 @@ In some case it is necessary to rebuild the `authorized_keys` file.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:shell:setup
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
|
||||
```
|
||||
|
@ -153,13 +153,13 @@ clear Redis' cache.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake cache:clear
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
|
||||
```
|
||||
|
@ -174,7 +174,7 @@ Omnibus packages.
|
|||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
|
||||
```
|
||||
|
@ -194,13 +194,13 @@ in the GitLab Performance Monitoring database.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:track_deployment
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
|
||||
```
|
||||
|
@ -213,13 +213,13 @@ is included to help you with this:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:tcp_check[example.com,80]
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
|
||||
```
|
||||
|
@ -238,13 +238,13 @@ To clear all exclusive leases:
|
|||
DANGER: **DANGER**:
|
||||
Don't run it while GitLab or Sidekiq is running
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:exclusive_lease:clear
|
||||
```
|
||||
|
||||
To specify a lease `type` or lease `type + id`, specify a scope:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# to clear all leases for repository garbage collection:
|
||||
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*]
|
||||
|
||||
|
@ -256,14 +256,14 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]
|
|||
|
||||
To check the status of migrations, you can use the following rake task:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake db:migrate:status
|
||||
```
|
||||
|
||||
This will output a table with a `Status` of `up` or `down` for
|
||||
each Migration ID.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
database: gitlabhq_production
|
||||
|
||||
Status Migration ID Migration Name
|
||||
|
@ -279,6 +279,6 @@ This could be as a result of [updating existing metrics](../../development/prome
|
|||
|
||||
To re-import the metrics you can run:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake metrics:setup_common_metrics
|
||||
```
|
||||
|
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
The GitLab Import/Export version can be checked by using:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Omnibus installations
|
||||
sudo gitlab-rake gitlab:import_export:version
|
||||
|
||||
|
@ -23,7 +23,7 @@ bundle exec rake gitlab:import_export:version RAILS_ENV=production
|
|||
|
||||
The current list of DB tables that will get exported can be listed by using:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Omnibus installations
|
||||
sudo gitlab-rake gitlab:import_export:data
|
||||
|
||||
|
|
|
@ -16,19 +16,19 @@ This task will schedule all your existing projects and attachments associated wi
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:migrate_to_hashed
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:migrate_to_hashed RAILS_ENV=production
|
||||
```
|
||||
|
||||
They both also accept a range as environment variable:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# to migrate any non migrated project from ID 20 to 50.
|
||||
export ID_FROM=20
|
||||
export ID_TO=50
|
||||
|
@ -63,19 +63,19 @@ Legacy storage type.
|
|||
|
||||
For Omnibus installations, run the following:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:rollback_to_legacy
|
||||
```
|
||||
|
||||
For source installations, run the following:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:rollback_to_legacy RAILS_ENV=production
|
||||
```
|
||||
|
||||
Both commands accept a range as environment variable:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# to rollback any migrated project from ID 20 to 50.
|
||||
export ID_FROM=20
|
||||
export ID_TO=50
|
||||
|
@ -95,13 +95,13 @@ To have a simple summary of projects using **Legacy** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:legacy_projects
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:legacy_projects RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -109,13 +109,13 @@ To list projects using **Legacy** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:list_legacy_projects
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:list_legacy_projects RAILS_ENV=production
|
||||
|
||||
```
|
||||
|
@ -126,13 +126,13 @@ To have a simple summary of projects using **Hashed** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:hashed_projects
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:hashed_projects RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -140,13 +140,13 @@ To list projects using **Hashed** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:list_hashed_projects
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:list_hashed_projects RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -156,13 +156,13 @@ To have a simple summary of project attachments using **Legacy** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:legacy_attachments
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:legacy_attachments RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -170,13 +170,13 @@ To list project attachments using **Legacy** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:list_legacy_attachments
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:list_legacy_attachments RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -186,13 +186,13 @@ To have a simple summary of project attachments using **Hashed** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:hashed_attachments
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:hashed_attachments RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
@ -200,13 +200,13 @@ To list project attachments using **Hashed** storage:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:list_hashed_attachments
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo -u git -H bundle exec rake gitlab:storage:list_hashed_attachments RAILS_ENV=production
|
||||
```
|
||||
|
||||
|
|
|
@ -17,13 +17,13 @@ described in the next section.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake "gitlab:uploads:migrate:all"
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate:all
|
||||
```
|
||||
|
||||
|
@ -52,7 +52,7 @@ Variable | Type | Description
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# gitlab-rake gitlab:uploads:migrate[uploader_class, model_class, mount_point]
|
||||
|
||||
# Avatars
|
||||
|
@ -80,7 +80,7 @@ gitlab-rake "gitlab:uploads:migrate[FileUploader, MergeRequest]"
|
|||
>**Note:**
|
||||
Use `RAILS_ENV=production` for every task.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# sudo -u git -H bundle exec rake gitlab:uploads:migrate
|
||||
|
||||
# Avatars
|
||||
|
@ -112,13 +112,13 @@ To migrate all uploads created by legacy uploaders, run:
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake gitlab:uploads:legacy:migrate
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
bundle exec rake gitlab:uploads:legacy:migrate
|
||||
```
|
||||
|
||||
|
@ -145,13 +145,13 @@ keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`.
|
|||
|
||||
**Omnibus Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rake "gitlab:uploads:migrate_to_local:all"
|
||||
```
|
||||
|
||||
**Source Installation**
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate_to_local:all
|
||||
```
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ You need `exiftool` installed on your system. If you installed GitLab:
|
|||
- Using the Omnibus package, you're all set.
|
||||
- From source, make sure `exiftool` is installed:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
# Debian/Ubuntu
|
||||
sudo apt-get install libimage-exiftool-perl
|
||||
|
||||
|
@ -22,7 +22,7 @@ Because EXIF data may contain sensitive information (e.g. GPS location), you
|
|||
can remove EXIF data also from existing images which were uploaded before
|
||||
with the following command:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif
|
||||
```
|
||||
|
||||
|
@ -46,13 +46,13 @@ each with a separate range of upload IDs (by setting `start_id` and `stop_id`).
|
|||
|
||||
To run the command without dry mode and remove EXIF data from all uploads, you can use:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[,,false,] 2>&1 | tee exif.log
|
||||
```
|
||||
|
||||
To run the command without dry mode on uploads with ID between 100 and 5000 and pause for 0.1 second, you can use:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[100,5000,false,0.1] 2>&1 | tee exif.log
|
||||
```
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
1. Install the `postfix` package if it is not installed already:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo apt-get install postfix
|
||||
```
|
||||
|
||||
|
@ -22,7 +22,7 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
1. Install the `mailutils` package.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo apt-get install mailutils
|
||||
```
|
||||
|
||||
|
@ -30,13 +30,13 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
1. Create a user for incoming email.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo useradd -m -s /bin/bash incoming
|
||||
```
|
||||
|
||||
1. Set a password for this user.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo passwd incoming
|
||||
```
|
||||
|
||||
|
@ -46,13 +46,13 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
1. Connect to the local SMTP server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
telnet localhost 25
|
||||
```
|
||||
|
||||
You should see a prompt like this:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
Trying 127.0.0.1...
|
||||
Connected to localhost.
|
||||
Escape character is '^]'.
|
||||
|
@ -61,13 +61,13 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
If you get a `Connection refused` error instead, verify that `postfix` is running:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postfix status
|
||||
```
|
||||
|
||||
If it is not, start it:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postfix start
|
||||
```
|
||||
|
||||
|
@ -94,7 +94,7 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
1. Check if the `incoming` user received the email:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
su - incoming
|
||||
mail
|
||||
```
|
||||
|
@ -108,13 +108,13 @@ The instructions make the assumption that you will be using the email address `i
|
|||
|
||||
Quit the mail app:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
q
|
||||
```
|
||||
|
||||
1. Log out of the `incoming` account and go back to being `root`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
logout
|
||||
```
|
||||
|
||||
|
@ -124,13 +124,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Configure Postfix to use Maildir-style mailboxes:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postconf -e "home_mailbox = Maildir/"
|
||||
```
|
||||
|
||||
1. Restart Postfix:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo /etc/init.d/postfix restart
|
||||
```
|
||||
|
||||
|
@ -139,7 +139,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
1. Follow steps 1 and 2 of _[Test the out-of-the-box setup](#test-the-out-of-the-box-setup)_.
|
||||
1. Check if the `incoming` user received the email:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
su - incoming
|
||||
MAIL=/home/incoming/Maildir
|
||||
mail
|
||||
|
@ -154,7 +154,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
Quit the mail app:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
q
|
||||
```
|
||||
|
||||
|
@ -166,7 +166,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Log out of the `incoming` account and go back to being `root`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
logout
|
||||
```
|
||||
|
||||
|
@ -174,25 +174,25 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Install the `courier-imap` package:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo apt-get install courier-imap
|
||||
```
|
||||
|
||||
And start `imapd`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
imapd start
|
||||
```
|
||||
|
||||
1. The courier-authdaemon isn't started after installation. Without it, imap authentication will fail:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo service courier-authdaemon start
|
||||
```
|
||||
|
||||
You can also configure courier-authdaemon to start on boot:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo systemctl enable courier-authdaemon
|
||||
```
|
||||
|
||||
|
@ -200,7 +200,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Let Postfix know about the domains that it should consider local:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postconf -e "mydestination = gitlab.example.com, localhost.localdomain, localhost"
|
||||
```
|
||||
|
||||
|
@ -208,25 +208,25 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
We'll assume `192.168.1.0/24` is your local LAN. You can safely skip this step if you don't have other machines in the same local network.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postconf -e "mynetworks = 127.0.0.0/8, 192.168.1.0/24"
|
||||
```
|
||||
|
||||
1. Configure Postfix to receive mail on all interfaces, which includes the internet:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postconf -e "inet_interfaces = all"
|
||||
```
|
||||
|
||||
1. Configure Postfix to use the `+` delimiter for sub-addressing:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo postconf -e "recipient_delimiter = +"
|
||||
```
|
||||
|
||||
1. Restart Postfix:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo service postfix restart
|
||||
```
|
||||
|
||||
|
@ -236,13 +236,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Connect to the SMTP server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
telnet gitlab.example.com 25
|
||||
```
|
||||
|
||||
You should see a prompt like this:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
Trying 123.123.123.123...
|
||||
Connected to gitlab.example.com.
|
||||
Escape character is '^]'.
|
||||
|
@ -269,7 +269,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Check if the `incoming` user received the email:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
su - incoming
|
||||
MAIL=/home/incoming/Maildir
|
||||
mail
|
||||
|
@ -284,13 +284,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
Quit the mail app:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
q
|
||||
```
|
||||
|
||||
1. Log out of the `incoming` account and go back to being `root`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
logout
|
||||
```
|
||||
|
||||
|
@ -298,13 +298,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Connect to the IMAP server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
telnet gitlab.example.com 143
|
||||
```
|
||||
|
||||
You should see a prompt like this:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
Trying 123.123.123.123...
|
||||
Connected to mail.example.gitlab.com.
|
||||
Escape character is '^]'.
|
||||
|
@ -327,7 +327,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
|
||||
1. Disconnect from the IMAP server:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
a logout
|
||||
```
|
||||
|
||||
|
|
|
@ -118,7 +118,7 @@ to validate. You can do so by specifying a range with the operation.
|
|||
This is an example of how to limit the rollout to Project IDs 50 to 100, running in
|
||||
an Omnibus GitLab installation:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
|
||||
```
|
||||
|
||||
|
@ -139,7 +139,7 @@ To schedule a complete rollback, see the
|
|||
The rollback task also supports specifying a range of Project IDs. Here is an example
|
||||
of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
|
||||
```
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ GitLab Rails application (Unicorn) as well as the other components, like:
|
|||
There may be times in the documentation where you will be asked to _restart_
|
||||
GitLab. In that case, you need to run the following command:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-ctl restart
|
||||
```
|
||||
|
||||
|
@ -51,13 +51,13 @@ ok: run: unicorn: (pid 11338) 0s
|
|||
To restart a component separately, you can append its service name to the
|
||||
`restart` command. For example, to restart **only** NGINX you would run:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-ctl restart nginx
|
||||
```
|
||||
|
||||
To check the status of GitLab services, run:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-ctl status
|
||||
```
|
||||
|
||||
|
@ -79,7 +79,7 @@ GitLab. Remember that this method applies only for the Omnibus packages.
|
|||
|
||||
Reconfigure Omnibus GitLab with:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
|
@ -152,7 +152,7 @@ the [cloud native Helm Chart](https://docs.gitlab.com/charts/). Usually, it shou
|
|||
enough to restart a specific component separately (`gitaly`, `unicorn`,
|
||||
`workhorse`, `gitlab-shell`, etc.) by deleting all the pods related to it:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl delete pods -l release=<helm release name>,app=<component name>
|
||||
```
|
||||
|
||||
|
|
|
@ -111,7 +111,7 @@ declined or an error occurs during the Git hook, your script should:
|
|||
|
||||
This hook script written in bash will generate the following message in GitLab's UI:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
#!/bin/sh
|
||||
echo "GL-HOOK-ERR: My custom error message.";
|
||||
exit 1
|
||||
|
|
|
@ -67,7 +67,7 @@ extensions), which contain the following in a single encrypted file:
|
|||
In order to export the required files in PEM encoding from the PKCS#12 file,
|
||||
the `openssl` command can be used:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
#-- Extract private key in PEM encoding (no password, unencrypted)
|
||||
$ openssl pkcs12 -in gitlab.p12 -nocerts -nodes -out gitlab.key
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@ The steps to configure this setting through the Rails console are:
|
|||
|
||||
1. Start the Rails console:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# For Omnibus installations
|
||||
sudo gitlab-rails console
|
||||
|
||||
|
@ -60,12 +60,12 @@ To retrieve the current value, start the Rails console and run:
|
|||
The process to set the snippets size limit through the Application Settings API is
|
||||
exactly the same as you would do to [update any other setting](../../api/settings.md#change-application-settings).
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?snippet_size_limit=52428800
|
||||
```
|
||||
|
||||
You can also use the API to [retrieve the current value](../../api/settings.md#get-current-application-settings).
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings
|
||||
```
|
||||
|
|
|
@ -31,7 +31,7 @@ gitlab_rails['time_zone'] = 'America/New_York'
|
|||
|
||||
After adding the configuration parameter, reconfigure and restart your GitLab instance:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
gitlab-ctl restart
|
||||
```
|
||||
|
|
|
@ -10,13 +10,13 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
|
|||
|
||||
1. Run a Rails console:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
sudo gitlab-rails console production
|
||||
```
|
||||
|
||||
or for source installs:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
bundle exec rails console production
|
||||
```
|
||||
|
||||
|
|
|
@ -332,7 +332,7 @@ bind ports 9200/9300 so it can be used.
|
|||
|
||||
The following is an example of running a docker container of Elasticsearch v7.2.0:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
docker pull docker.elastic.co/elasticsearch/elasticsearch:7.2.0
|
||||
docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.2.0
|
||||
```
|
||||
|
|
|
@ -30,7 +30,7 @@ should and, if needed, update the script for the latest version of GitLab.
|
|||
If the script you want to run is short, you can use the Rails Runner to avoid
|
||||
entering the rails console in the first place. Here's an example of its use:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gitlab-rails runner "RAILS_COMMAND"
|
||||
|
||||
# Example with a 2-line script
|
||||
|
@ -130,19 +130,19 @@ end
|
|||
|
||||
### Check the GitLab version fast
|
||||
|
||||
```bash
|
||||
```shell
|
||||
grep -m 1 gitlab /opt/gitlab/version-manifest.txt
|
||||
```
|
||||
|
||||
### Debugging SSH
|
||||
|
||||
```bash
|
||||
```shell
|
||||
GIT_SSH_COMMAND="ssh -vvv" git clone <repository>
|
||||
```
|
||||
|
||||
### Debugging over HTTPS
|
||||
|
||||
```bash
|
||||
```shell
|
||||
GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone <repository>
|
||||
```
|
||||
|
||||
|
@ -301,19 +301,19 @@ correctly named empty project using the steps below.
|
|||
|
||||
Move the new repository to the empty repository:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
mv /var/opt/gitlab/git-data/repositories/<group>/<new-project> /var/opt/gitlab/git-data/repositories/<group>/<empty-project>
|
||||
```
|
||||
|
||||
Make sure the permissions are correct:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
chown -R git:git <path-to-directory>.git
|
||||
```
|
||||
|
||||
Clear the cache:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
sudo gitlab-rake cache:clear
|
||||
```
|
||||
|
||||
|
@ -489,7 +489,7 @@ User.active.count
|
|||
::HistoricalData.max_historical_user_count
|
||||
```
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Using curl and jq (up to a max 100, see pagination docs https://docs.gitlab.com/ee/api/#pagination
|
||||
curl --silent --header "Private-Token: ********************" "https://gitlab.example.com/api/v4/users?per_page=100&active" | jq --compact-output '.[] | [.id,.name,.username]'
|
||||
```
|
||||
|
@ -995,13 +995,13 @@ See <https://github.com/mperham/sidekiq/wiki/Signals#ttin>.
|
|||
|
||||
### Connect to Redis (omnibus)
|
||||
|
||||
```sh
|
||||
```shell
|
||||
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
|
||||
```
|
||||
|
||||
### Connect to Redis (HA)
|
||||
|
||||
```sh
|
||||
```shell
|
||||
/opt/gitlab/embedded/bin/redis-cli -h <host ip> -a <password>
|
||||
```
|
||||
|
||||
|
@ -1034,7 +1034,7 @@ This script will go through all the encrypted variables and count how many are n
|
|||
to be decrypted. Might be helpful to run on multiple nodes to see which `gitlab-secrets.json`
|
||||
file is most up to date:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
wget -O /tmp/bad-decrypt.rb https://gitlab.com/snippets/1730735/raw
|
||||
gitlab-rails runner /tmp/bad-decrypt.rb
|
||||
```
|
||||
|
@ -1075,7 +1075,7 @@ two-factor authentication.
|
|||
This script will search for all encrypted tokens that are causing decryption errors,
|
||||
and update or reset as needed:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
wget -O /tmp/encrypted-tokens.rb https://gitlab.com/snippets/1876342/raw
|
||||
gitlab-rails runner /tmp/encrypted-tokens.rb
|
||||
```
|
||||
|
|
|
@ -20,13 +20,13 @@ and they will assist you with any issues you are having.
|
|||
- How to authorize to your GCP project (can be especially useful if you have projects
|
||||
under different GCP accounts):
|
||||
|
||||
```bash
|
||||
```shell
|
||||
gcloud auth login
|
||||
```
|
||||
|
||||
- How to access Kubernetes dashboard:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# for minikube:
|
||||
minikube dashboard —url
|
||||
# for non-local installations if access via Kubectl is configured:
|
||||
|
@ -42,7 +42,7 @@ and they will assist you with any issues you are having.
|
|||
|
||||
- How to copy a file from local machine to a pod:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl cp file-name pod-name:./destination-path
|
||||
```
|
||||
|
||||
|
@ -51,19 +51,19 @@ and they will assist you with any issues you are having.
|
|||
- Check logs via Kubernetes dashboard.
|
||||
- Check logs via Kubectl:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl logs <unicorn pod> -c dependencies
|
||||
```
|
||||
|
||||
- How to tail all Kubernetes cluster events in real time:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl get events -w --all-namespaces
|
||||
```
|
||||
|
||||
- How to get logs of the previously terminated pod instance:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl logs <pod-name> --previous
|
||||
```
|
||||
|
||||
|
@ -79,13 +79,13 @@ and they will assist you with any issues you are having.
|
|||
|
||||
- Tailing logs of a separate pod. An example for a Unicorn pod:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn
|
||||
```
|
||||
|
||||
- Tail and follow all pods that share a label (in this case, `unicorn`):
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# all containers in the unicorn pods
|
||||
kubectl logs -f -l app=unicorn --all-containers=true --max-log-requests=50
|
||||
|
||||
|
@ -96,21 +96,21 @@ and they will assist you with any issues you are having.
|
|||
- One can stream logs from all containers at once, similar to the Omnibus
|
||||
command `gitlab-ctl tail`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100
|
||||
```
|
||||
|
||||
- Check all events in the `gitlab` namespace (the namespace name can be different if you
|
||||
specified a different one when deploying the Helm chart):
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl get events -w --namespace=gitlab
|
||||
```
|
||||
|
||||
- Most of the useful GitLab tools (console, rake tasks, etc) are found in the task-runner
|
||||
pod. You may enter it and run commands inside or run them from the outside:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# find the pod
|
||||
kubectl get pods | grep task-runner
|
||||
|
||||
|
@ -145,7 +145,7 @@ and they will assist you with any issues you are having.
|
|||
|
||||
- How to get your initial admin password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# find the name of the secret containing the password
|
||||
kubectl get secrets | grep initial-root
|
||||
# decode it
|
||||
|
@ -154,19 +154,19 @@ and they will assist you with any issues you are having.
|
|||
|
||||
- How to connect to a GitLab Postgres database:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole -p
|
||||
```
|
||||
|
||||
- How to get info about Helm installation status:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
helm status name-of-installation
|
||||
```
|
||||
|
||||
- How to update GitLab installed using Helm Chart:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
helm repo upgrade
|
||||
|
||||
# get current values and redirect them to yaml file (analogue of gitlab.rb values)
|
||||
|
@ -185,7 +185,7 @@ and they will assist you with any issues you are having.
|
|||
- Modify the `gitlab.yaml` file.
|
||||
- Run the following command to apply changes:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
helm upgrade <release name> <chart path> -f gitlab.yaml
|
||||
```
|
||||
|
||||
|
@ -197,20 +197,20 @@ to those documents for details.
|
|||
|
||||
- Install Kubectl via Homebrew:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
brew install kubernetes-cli
|
||||
```
|
||||
|
||||
- Install Minikube via Homebrew:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
brew cask install minikube
|
||||
```
|
||||
|
||||
- Start Minikube and configure it. If Minikube cannot start, try running `minikube delete && minikube start`
|
||||
and repeat the steps:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
|
||||
minikube addons enable ingress
|
||||
minikube addons enable kube-dns
|
||||
|
@ -218,7 +218,7 @@ to those documents for details.
|
|||
|
||||
- Install Helm via Homebrew and initialize it:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
brew install kubernetes-helm
|
||||
helm init --service-account tiller
|
||||
```
|
||||
|
@ -231,7 +231,7 @@ to those documents for details.
|
|||
|
||||
- Install the GitLab Helm Chart:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
helm repo add gitlab https://charts.gitlab.io
|
||||
helm install --name gitlab -f <path-to-yaml-file> gitlab/gitlab
|
||||
```
|
||||
|
|
|
@ -23,7 +23,7 @@ on. Contributions are welcome to help add them.
|
|||
|
||||
### Distro Information
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Debian/Ubuntu
|
||||
uname -a
|
||||
lsb_release -a
|
||||
|
@ -38,14 +38,14 @@ cat /etc/os-release
|
|||
|
||||
### Shut down or Reboot
|
||||
|
||||
```bash
|
||||
```shell
|
||||
shutdown -h now
|
||||
reboot
|
||||
```
|
||||
|
||||
### Permissions
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# change the user:group ownership of a file/dir
|
||||
chown root:git <file_or_dir>
|
||||
|
||||
|
@ -55,7 +55,7 @@ chmod u+x <file>
|
|||
|
||||
### Files & Dirs
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# create a new directory and all subdirectories
|
||||
mkdir -p dir/dir2/dir3
|
||||
|
||||
|
@ -71,7 +71,7 @@ sed -i 's/original-text/new-text/g' <filename>
|
|||
|
||||
### See all set environment variables
|
||||
|
||||
```bash
|
||||
```shell
|
||||
env
|
||||
```
|
||||
|
||||
|
@ -79,7 +79,7 @@ env
|
|||
|
||||
### File names
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# search for a file in a filesystem
|
||||
find . -name 'filename.rb' -print
|
||||
|
||||
|
@ -95,7 +95,7 @@ history
|
|||
|
||||
### File contents
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# -B/A = show 2 lines before/after search_term
|
||||
grep -B 2 -A 2 search_term <filename>
|
||||
|
||||
|
@ -114,7 +114,7 @@ fgrep -R string_pattern <filename or directory>
|
|||
|
||||
### CLI
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# View command history
|
||||
history
|
||||
|
||||
|
@ -132,7 +132,7 @@ sudo !!
|
|||
|
||||
### Memory, Disk, & CPU usage
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# disk space info. The '-h' gives the data in human-readable values
|
||||
df -h
|
||||
|
||||
|
@ -157,7 +157,7 @@ top -o %CPU
|
|||
|
||||
### Strace
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# strace a process
|
||||
strace -tt -T -f -y -s 1024 -p <pid>
|
||||
|
||||
|
@ -200,7 +200,7 @@ can also sort based on total time, # of syscalls made, PID #, and # of child pro
|
|||
using the `-S` or `--sort` flag. The number of results defaults to 25 processes, but
|
||||
can be changed using the `-c`/`--count` option. See `--help` for full details.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
$ ./strace-parser strace.txt
|
||||
|
||||
Top 25 PIDs
|
||||
|
@ -218,7 +218,7 @@ Based on the summary, you can then view the details of syscalls made by one or m
|
|||
procsses using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for
|
||||
a sorted list. `--stats` takes the same sorting and count options as summary.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
$ ./strace-parse strace.text -p 6423
|
||||
|
||||
PID 6423
|
||||
|
@ -274,7 +274,7 @@ small differences should not be considered significant.
|
|||
|
||||
### Ports
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Find the programs that are listening on ports
|
||||
netstat -plnt
|
||||
ss -plnt
|
||||
|
@ -283,7 +283,7 @@ lsof -i -P | grep <port>
|
|||
|
||||
### Internet/DNS
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Show domain IP address
|
||||
dig +short example.com
|
||||
nslookup example.com
|
||||
|
@ -302,7 +302,7 @@ curl --head --location https://example.com
|
|||
|
||||
## Package Management
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Debian/Ubuntu
|
||||
|
||||
# List packages
|
||||
|
@ -332,7 +332,7 @@ rpm -qa | grep <package>
|
|||
|
||||
## Logs
|
||||
|
||||
```bash
|
||||
```shell
|
||||
# Print last lines in log file where 'n'
|
||||
# is the number of lines to print
|
||||
tail -n /path/to/log/file
|
||||
|
|
|
@ -83,13 +83,13 @@ To fix this problem:
|
|||
|
||||
If your GitLab instance is using a self-signed certificate, or the certificate is signed by an internal certificate authority (CA), you might run into the following errors when attempting to perform Git operations:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
$ git clone https://gitlab.domain.tld/group/project.git
|
||||
Cloning into 'project'...
|
||||
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate
|
||||
```
|
||||
|
||||
```bash
|
||||
```shell
|
||||
$ git clone https://gitlab.domain.tld/group/project.git
|
||||
Cloning into 'project'...
|
||||
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
|
||||
|
@ -107,6 +107,6 @@ To fix this problem:
|
|||
|
||||
- Disable SSL verification in your Git client. Note that this intended as a temporary measure as it could be considered a **security risk**.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git config --global http.sslVerify false
|
||||
```
|
||||
|
|
|
@ -37,7 +37,7 @@ you change a few things:
|
|||
|
||||
For example, when the `docker-machine` host we want to use is `do-docker`:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
docker run --detach --name gitlab \
|
||||
--env GITLAB_OMNIBUS_CONFIG="external_url 'http://$(docker-machine ip do-docker)'; gitlab_rails['gitlab_shell_ssh_port'] = 2222;" \
|
||||
--hostname $(docker-machine ip do-docker) \
|
||||
|
@ -52,7 +52,7 @@ gitlab/gitlab-ee:11.5.3-ee.0
|
|||
We can use the [`test-saml-idp` Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
|
||||
to do the work for us:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \
|
||||
-e SIMPLESAMLPHP_SP_ENTITY_ID=<GITLAB_IP_OR_DOMAIN> \
|
||||
-e SIMPLESAMLPHP_SP_ASSERTION_CONSUMER_SERVICE=<GITLAB_IP_OR_DOMAIN>/users/auth/saml/callback \
|
||||
|
@ -93,7 +93,7 @@ See [the GDK SAML documentation](https://gitlab.com/gitlab-org/gitlab-developmen
|
|||
|
||||
### Elasticsearch
|
||||
|
||||
```sh
|
||||
```shell
|
||||
docker run -d --name elasticsearch \
|
||||
-p 9200:9200 -p 9300:9300 \
|
||||
-e "discovery.type=single-node" \
|
||||
|
@ -110,7 +110,7 @@ on running PlantUML in Docker.
|
|||
|
||||
### Jira
|
||||
|
||||
```sh
|
||||
```shell
|
||||
docker run -d -p 8081:8080 cptactionhank/atlassian-jira:latest
|
||||
```
|
||||
|
||||
|
@ -119,7 +119,7 @@ Jira license.
|
|||
|
||||
### Grafana
|
||||
|
||||
```sh
|
||||
```shell
|
||||
docker run -d --name grafana -e "GF_SECURITY_ADMIN_PASSWORD=gitlab" -p 3000:3000 grafana/grafana
|
||||
```
|
||||
|
||||
|
|
|
@ -335,7 +335,7 @@ resources you can pass the following parameters:
|
|||
|
||||
In the example below, we list 50 [namespaces](namespaces.md) per page.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/namespaces?per_page=50"
|
||||
```
|
||||
|
||||
|
@ -349,7 +349,7 @@ In the cURL example below, we limit the output to 3 items per page (`per_page=3`
|
|||
and we request the second page (`page=2`) of [comments](notes.md) of the issue
|
||||
with ID `8` which belongs to the project with ID `8`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --head --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/8/issues/8/notes?per_page=3&page=2
|
||||
```
|
||||
|
||||
|
@ -409,7 +409,7 @@ This method is controlled by the following parameters:
|
|||
|
||||
In the example below, we list 50 [projects](projects.md) per page, ordered by `id` ascending.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc"
|
||||
```
|
||||
|
||||
|
@ -472,7 +472,7 @@ We can call the API with `array` and `hash` types parameters as shown below:
|
|||
|
||||
`import_sources` is a parameter of type `array`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
|
||||
-d "import_sources[]=github" \
|
||||
-d "import_sources[]=bitbucket" \
|
||||
|
@ -483,7 +483,7 @@ https://gitlab.example.com/api/v4/some_endpoint
|
|||
|
||||
`override_params` is a parameter of type `hash`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
|
||||
--form "namespace=email" \
|
||||
--form "path=impapi" \
|
||||
|
@ -497,7 +497,7 @@ https://gitlab.example.com/api/v4/projects/import
|
|||
|
||||
`variables` is a parameter of type `array` containing hash key/value pairs `[{ 'key' => 'UPLOAD_TO_S3', 'value' => 'true' }]`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --globoff --request POST --header "PRIVATE-TOKEN: ********************" \
|
||||
"https://gitlab.example.com/api/v4/projects/169/pipeline?ref=master&variables[][key]=VAR1&variables[][value]=hello&variables[][key]=VAR2&variables[][value]=world"
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ GET /projects/:id/access_requests
|
|||
|
||||
Example request:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests
|
||||
```
|
||||
|
@ -72,7 +72,7 @@ POST /projects/:id/access_requests
|
|||
|
||||
Example request:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests
|
||||
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests
|
||||
```
|
||||
|
@ -107,7 +107,7 @@ PUT /projects/:id/access_requests/:user_id/approve
|
|||
|
||||
Example request:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests/:user_id/approve?access_level=20
|
||||
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests/:user_id/approve?access_level=20
|
||||
```
|
||||
|
@ -141,7 +141,7 @@ DELETE /projects/:id/access_requests/:user_id
|
|||
|
||||
Example request:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests/:user_id
|
||||
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/access_requests/:user_id
|
||||
```
|
||||
|
|
|
@ -13,7 +13,7 @@ List the current appearance configuration of the GitLab instance.
|
|||
GET /application/appearance
|
||||
```
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/appearance
|
||||
```
|
||||
|
||||
|
@ -57,7 +57,7 @@ PUT /application/appearance
|
|||
| `message_font_color` | string | no | Font color for the system header / footer bar
|
||||
| `email_header_and_footer_enabled` | boolean | no | Add header and footer to all outgoing emails if enabled
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/appearance?email_header_and_footer_enabled=true&header_message=test
|
||||
```
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ Parameters:
|
|||
|
||||
Example request:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --data "name=MyApplication&redirect_uri=http://redirect.uri&scopes=" https://gitlab.example.com/api/v4/applications
|
||||
```
|
||||
|
||||
|
@ -58,7 +58,7 @@ GET /applications
|
|||
|
||||
Example request:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/applications
|
||||
```
|
||||
|
||||
|
@ -97,6 +97,6 @@ Parameters:
|
|||
|
||||
Example request:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/applications/:id
|
||||
```
|
||||
|
|
|
@ -24,7 +24,7 @@ are paginated.
|
|||
|
||||
Read more on [pagination](README.md#pagination).
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/audit_events
|
||||
```
|
||||
|
||||
|
@ -91,7 +91,7 @@ Example response:
|
|||
GET /audit_events/:id
|
||||
```
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/audit_events/1
|
||||
```
|
||||
|
||||
|
@ -141,7 +141,7 @@ are paginated.
|
|||
|
||||
Read more on [pagination](README.md#pagination).
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/groups/60/audit_events
|
||||
```
|
||||
|
||||
|
@ -197,7 +197,7 @@ GET /groups/:id/audit_events/:audit_event_id
|
|||
| `id` | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) |
|
||||
| `audit_event_id` | integer | yes | ID of the audit event |
|
||||
|
||||
```bash
|
||||
```shell
|
||||
curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/groups/60/audit_events/2
|
||||
```
|
||||
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue