Skip to content
Snippets Groups Projects
Commit 33c867b7 authored by Marcel Amirault's avatar Marcel Amirault Committed by Achilleas Pipinellis
Browse files

Fix whitespace in install and integration docs 

Many code blocks are 4spaced, and they render in GitLab
without coloring as a result, even though they are
fenced with a language label. If in a list, other items
will render as being in a code block too, even if not
meant to. This fixes all these issues, and cleans up
minor white space issues in install and integration docs
parent 3b423390
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 986 additions and 969 deletions
doc/install/aws/index.md
+ 69
− 68
View file @ 33c867b7
@@ -59,10 +59,11 @@ Here's a list of the AWS services we will use, with links to pricing information
- **ElastiCache**: An in-memory cache environment will be used to provide a
High Availability Redis configuration. See the
[Amazon ElastiCache pricing](https://aws.amazon.com/elasticache/pricing/).
NOTE: **Note:** Please note that while we will be using EBS for storage, we do not recommend using EFS as it may negatively impact GitLab's performance. You can review the [relevant documentation](../../administration/high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
 
## Creating an IAM EC2 instance role and profile
To minimize the permissions of the user, we'll create a new [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)
role with limited access:
 
@@ -90,7 +91,7 @@ We'll now create a VPC, a virtual networking environment that you'll control:
`10.0.0.0/16`. If you don't require dedicated hardware, you can leave
"Tenancy" as default. Click **Yes, Create** when ready.
 
![Create VPC](img/create_vpc.png)
![Create VPC](img/create_vpc.png)
 
### Subnets
 
@@ -107,16 +108,16 @@ RDS instances as well:
for example `gitlab-public-10.0.0.0`, select the VPC we created previously,
and at the IPv4 CIDR block let's give it a 24 subnet `10.0.0.0/24`:
 
![Create subnet](img/create_subnet.png)
![Create subnet](img/create_subnet.png)
 
1. Follow the same steps to create all subnets:
 
| Name tag | Type |Availability Zone | CIDR block |
| -------- | ---- | ---------------- | ---------- |
| gitlab-public-10.0.0.0 | public | us-west-2a | 10.0.0.0 |
| gitlab-private-10.0.1.0 | private | us-west-2a | 10.0.1.0 |
| gitlab-public-10.0.2.0 | public | us-west-2b | 10.0.2.0 |
| gitlab-private-10.0.3.0 | private | us-west-2b | 10.0.3.0 |
| Name tag | Type |Availability Zone | CIDR block |
| -------- | ---- | ---------------- | ---------- |
| gitlab-public-10.0.0.0 | public | us-west-2a | 10.0.0.0 |
| gitlab-private-10.0.1.0 | private | us-west-2a | 10.0.1.0 |
| gitlab-public-10.0.2.0 | public | us-west-2b | 10.0.2.0 |
| gitlab-private-10.0.3.0 | private | us-west-2b | 10.0.3.0 |
 
### Route Table
 
@@ -139,7 +140,7 @@ create a new one:
1. Select it from the table, and then under the **Actions** dropdown choose
"Attach to VPC".
 
![Create gateway](img/create_gateway.png)
![Create gateway](img/create_gateway.png)
 
1. Choose `gitlab-vpc` from the list and hit **Attach**.
 
@@ -154,14 +155,14 @@ it receive traffic from any destination.
as destination. In the target, select the `gitlab-gateway` we created previously.
Hit **Save** once done.
 
![Associate subnet with gateway](img/associate_subnet_gateway.png)
![Associate subnet with gateway](img/associate_subnet_gateway.png)
 
Next, we must associate the **public** subnets to the route table:
 
1. Select the **Subnet Associations** tab and hit **Edit**.
1. Check only the public subnet and hit **Save**.
 
![Associate subnet with gateway](img/associate_subnet_gateway_2.png)
![Associate subnet with gateway](img/associate_subnet_gateway_2.png)
 
---
 
@@ -178,12 +179,12 @@ The security group is basically the firewall:
Inbound Rules tab. You will need to open the SSH, HTTP, and HTTPS ports. Set
the source to `0.0.0.0/0`.
 
![Create security group](img/create_security_group.png)
![Create security group](img/create_security_group.png)
 
TIP: **Tip:**
Based on best practices, you should allow SSH traffic from only a known
host or CIDR block. In that case, change the SSH source to be custom and give
it the IP you want to SSH from.
TIP: **Tip:**
Based on best practices, you should allow SSH traffic from only a known
host or CIDR block. In that case, change the SSH source to be custom and give
it the IP you want to SSH from.
 
1. When done, click **Save**.
 
@@ -204,7 +205,7 @@ create the actual RDS instance.
we defined them in the [subnets section](#subnets)).
Click **Create** when ready.
 
![RDS Subnet Group](img/rds_subnet_group.png)
![RDS Subnet Group](img/rds_subnet_group.png)
 
### Creating the database
 
@@ -214,17 +215,17 @@ Now, it's time to create the database:
1. Select PostgreSQL and click **Next**.
1. Since this is a production server, let's choose "Production". Click **Next**.
1. Let's see the instance specifications:
1. Leave the license model as is (`postgresql-license`).
1. For the version, select the latest of the 9.6 series (check the
[database requirements](../../install/requirements.md#postgresql-requirements))
if there are any updates on this).
1. For the size, let's select a `t2.medium` instance.
1. Multi-AZ-deployment is recommended as redundancy, so choose "Create
replica in different zone". Read more at
[High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
1. A Provisioned IOPS (SSD) storage type is best suited for HA (though you can
choose a General Purpose (SSD) to reduce the costs). Read more about it at
[Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
1. Leave the license model as is (`postgresql-license`).
1. For the version, select the latest of the 9.6 series (check the
[database requirements](../../install/requirements.md#postgresql-requirements))
if there are any updates on this).
1. For the size, let's select a `t2.medium` instance.
1. Multi-AZ-deployment is recommended as redundancy, so choose "Create
replica in different zone". Read more at
[High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
1. A Provisioned IOPS (SSD) storage type is best suited for HA (though you can
choose a General Purpose (SSD) to reduce the costs). Read more about it at
[Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
 
1. The rest of the settings on this page request a DB isntance identifier, username
and a master password. We've chosen to use `gitlab-db-ha`, `gitlab` and a
@@ -232,9 +233,9 @@ Now, it's time to create the database:
1. Click **Next** to proceed to the advanced settings.
1. Make sure to choose our gitlab VPC, our subnet group, set public accessibility to
**No**, and to leave it to create a new security group. The only additional
change which will be helpful is the database name for which we can use
`gitlabhq_production`. At the very bottom, there's an option to enable
auto updates to minor versions. You may want to turn it off.
change which will be helpful is the database name for which we can use
`gitlabhq_production`. At the very bottom, there's an option to enable
auto updates to minor versions. You may want to turn it off.
1. When done, click **Create database**.
 
### Installing the `pg_trgm` extension for PostgreSQL
@@ -276,7 +277,7 @@ To set up Redis:
Make sure to select our VPC and its [private subnets](#subnets). Click
**Create** when ready.
 
![ElastiCache subnet](img/ec_subnet.png)
![ElastiCache subnet](img/ec_subnet.png)
 
1. Select **Redis** on the left menu and click **Create** to create a new
Redis cluster. Depending on your load, you can choose whether to enable
@@ -284,16 +285,16 @@ To set up Redis:
chance to deploy Redis in multi availability zones. In this guide, we chose
not to enable it.
1. In the settings section:
1. Give the cluster a name (`gitlab-redis`) and a description.
1. For the version, select the latest of `3.2` series (e.g., `3.2.10`).
1. Select the node type and the number of replicas.
1. Give the cluster a name (`gitlab-redis`) and a description.
1. For the version, select the latest of `3.2` series (e.g., `3.2.10`).
1. Select the node type and the number of replicas.
1. In the advanced settings section:
1. Select the multi-AZ auto-failover option.
1. Select the subnet group we created previously.
1. Manually select the preferred availability zones, and under "Replica 2"
choose a different zone than the other two.
 
![Redis availability zones](img/ec_az.png)
![Redis availability zones](img/ec_az.png)
 
1. In the security settings, edit the security groups and choose the
`gitlab-security-group` we had previously created.
@@ -316,11 +317,11 @@ and add a custom TCP rule for port `6379` accessible within itself.
On the EC2 dashboard, look for Load Balancer on the left column:
 
1. Click the **Create Load Balancer** button.
1. Choose the Application Load Balancer.
1. Give it a name (`gitlab-loadbalancer`) and set the scheme to "internet-facing".
1. In the "Listeners" section, make sure it has HTTP and HTTPS.
1. In the "Availability Zones" section, select the `gitlab-vpc` we have created
and associate the **public subnets**.
1. Choose the Application Load Balancer.
1. Give it a name (`gitlab-loadbalancer`) and set the scheme to "internet-facing".
1. In the "Listeners" section, make sure it has HTTP and HTTPS.
1. In the "Availability Zones" section, select the `gitlab-vpc` we have created
and associate the **public subnets**.
1. Click **Configure Security Settings** to go to the next section to
select the TLS certificate. When done, go to the next step.
1. In the "Security Groups" section, create a new one by giving it a name
@@ -355,7 +356,7 @@ Choose the AMI:
where `<version>` the latest version as seen on the
[releases page](https://about.gitlab.com/releases/).
 
![Choose AMI](img/choose_ami.png)
![Choose AMI](img/choose_ami.png)
 
### Choose an instance type
 
@@ -504,19 +505,19 @@ The EBS volume will host the Git repositories data:
1. Tell GitLab to store its data in the new directory by editing
`/etc/gitlab/gitlab.rb` with your editor:
 
```ruby
git_data_dirs({
"default" => { "path" => "/mnt/gitlab-data" }
})
```
```ruby
git_data_dirs({
"default" => { "path" => "/mnt/gitlab-data" }
})
```
 
where `/mnt/gitlab-data` the location where you will store the Git data.
where `/mnt/gitlab-data` the location where you will store the Git data.
 
1. Save the file and reconfigure GitLab:
 
```sh
sudo gitlab-ctl reconfigure
```
```sh
sudo gitlab-ctl reconfigure
```
 
TIP: **Tip:**
If you wish to add more than one data volumes to store the Git repositories,
@@ -549,15 +550,15 @@ After you SSH into the instance, configure the domain name:
1. Open `/etc/gitlab/gitlab.rb` with your preferred editor.
1. Edit the `external_url` value:
 
```ruby
external_url 'http://example.com'
```
```ruby
external_url 'http://example.com'
```
 
1. Reconfigure GitLab:
 
```sh
sudo gitlab-ctl reconfigure
```
```sh
sudo gitlab-ctl reconfigure
```
 
You should now be able to reach GitLab at the URL you defined. To use HTTPS
(recommended), see the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
@@ -608,9 +609,9 @@ To back up GitLab:
1. SSH into your instance.
1. Take a backup:
 
```sh
sudo gitlab-rake gitlab:backup:create
```
```sh
sudo gitlab-rake gitlab:backup:create
```
 
### Restoring GitLab from a backup
 
@@ -626,16 +627,16 @@ released, you can update your GitLab instance:
1. SSH into your instance
1. Take a backup:
 
```sh
sudo gitlab-rake gitlab:backup:create
```
```sh
sudo gitlab-rake gitlab:backup:create
```
 
1. Update the repositories and install GitLab:
 
```sh
sudo apt update
sudo apt install gitlab-ee
```
```sh
sudo apt update
sudo apt install gitlab-ee
```
 
After a few minutes, the new version should be up and running.
 
doc/install/azure/index.md
+ 17
− 14
View file @ 33c867b7
@@ -67,18 +67,19 @@ The first items we need to configure are the basic settings of the underlying vi
1. Enter a `User name` - e.g. **"gitlab-admin"**
1. Select an `Authentication type`, either **SSH public key** or **Password**:
 
> **Note:** if you're unsure which authentication type to use, select **Password**
> **Note:** if you're unsure which authentication type to use, select **Password**
1. If you chose **SSH public key** - enter your `SSH public key` into the field provided
_(read the [SSH documentation][GitLab-Docs-SSH] to learn more about how to set up SSH
public keys)_
1. If you chose **Password** - enter the password you wish to use _(this is the password that you
will use later in this tutorial to [SSH] into the VM, so make sure it's a strong password/passphrase)_
 
1. If you chose **SSH public key** - enter your `SSH public key` into the field provided
_(read the [SSH documentation][GitLab-Docs-SSH] to learn more about how to set up SSH
public keys)_
1. If you chose **Password** - enter the password you wish to use _(this is the password that you
will use later in this tutorial to [SSH] into the VM, so make sure it's a strong password/passphrase)_
1. Choose the appropriate `Subscription` tier for your Azure account
1. Choose an existing `Resource Group` or create a new one - e.g. **"GitLab-CE-Azure"**
 
> **Note:** a "Resource group" is a way to group related resources together for easier administration.
> We chose "GitLab-CE-Azure", but your resource group can have the same name as your VM.
> **Note:** a "Resource group" is a way to group related resources together for easier administration.
> We chose "GitLab-CE-Azure", but your resource group can have the same name as your VM.
 
1. Choose a `Location` - if you're unsure, select the default location
 
@@ -248,6 +249,7 @@ rules in the list:
![Azure - Inbound security rules - List](img/azure-inbound-sec-rules-list.png)
 
## Connecting to GitLab
Use the domain name you set up earlier (or the public IP address) to visit your new GitLab instance
in your browser. If everything has gone according to plan you should be presented with the
following page, asking you to set a _new_ password for the administrator account automatically
@@ -348,6 +350,7 @@ your VM, you can use the IP address in its place in the following command:
```bash
ssh username@your-azure-domain-name.com
```
Provide your password at the prompt to authenticate.
 
#### SSH from Windows (PuTTY)
@@ -411,12 +414,12 @@ Check out our other [Technical Articles][GitLab-Technical-Articles] or browse th
- [GitLab Community Edition][CE]
- [GitLab Enterprise Edition][EE]
- [Microsoft Azure][Azure]
- [Azure - Free Account FAQ][Azure-Free-Account-FAQ]
- [Azure - Marketplace][Azure-Marketplace]
- [Azure Portal][Azure-Portal]
- [Azure - Pricing Calculator][Azure-Pricing-Calculator]
- [Azure - Troubleshoot SSH Connections to an Azure Linux VM][Azure-Troubleshoot-SSH-Connection]
- [Azure - Properly Shutdown an Azure VM][Azure-Properly-Shutdown-VM]
- [Azure - Free Account FAQ][Azure-Free-Account-FAQ]
- [Azure - Marketplace][Azure-Marketplace]
- [Azure Portal][Azure-Portal]
- [Azure - Pricing Calculator][Azure-Pricing-Calculator]
- [Azure - Troubleshoot SSH Connections to an Azure Linux VM][Azure-Troubleshoot-SSH-Connection]
- [Azure - Properly Shutdown an Azure VM][Azure-Properly-Shutdown-VM]
- [SSH], [PuTTY] and [Using SSH in PuTTY][Using-SSH-In-Putty]
 
[Original-Blog-Post]: https://about.gitlab.com/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/ "How to Set up a GitLab Instance on Microsoft Azure"
doc/install/digitaloceandocker.md
+ 16
− 16
View file @ 33c867b7
@@ -36,30 +36,30 @@ The rest of the steps are identical for macOS and Linux.
1. Login to Digital Ocean.
1. Generate a new API token at <https://cloud.digitalocean.com/settings/api/tokens>.
 
This command will create a new DO droplet called `gitlab-test-env-do` that will act as a docker host.
This command will create a new DO droplet called `gitlab-test-env-do` that will act as a docker host.
 
NOTE: **Note:**
4GB is the minimum requirement for a Docker host that will run more than one GitLab instance.
NOTE: **Note:**
4GB is the minimum requirement for a Docker host that will run more than one GitLab instance.
 
- RAM: 4GB
- Name: `gitlab-test-env-do`
- Driver: `digitalocean`
- RAM: 4GB
- Name: `gitlab-test-env-do`
- Driver: `digitalocean`
 
1. Set the DO token:
 
```sh
export DOTOKEN=<your generated token>
```
```sh
export DOTOKEN=<your generated token>
```
 
1. Create the machine:
 
```sh
docker-machine create \
--driver digitalocean \
--digitalocean-access-token=$DOTOKEN \
--digitalocean-size "4gb" \
gitlab-test-env-do
```
```sh
docker-machine create \
--driver digitalocean \
--digitalocean-access-token=$DOTOKEN \
--digitalocean-size "4gb" \
gitlab-test-env-do
```
 
Resource: <https://docs.docker.com/machine/drivers/digital-ocean/>.
 
doc/install/google_cloud_platform/index.md
+ 19
− 19
View file @ 33c867b7
@@ -30,16 +30,16 @@ To deploy GitLab on GCP you first need to create a virtual machine:
1. Go to <https://console.cloud.google.com/compute/instances> and log in with your Google credentials.
1. Click on **Create**
 
![Search for GitLab](img/launch_vm.png)
![Search for GitLab](img/launch_vm.png)
 
1. On the next page, you can select the type of VM as well as the
1. On the next page, you can select the type of VM as well as the
estimated costs. Provide the name of the instance, desired datacenter, and machine type. Note that GitLab recommends at least 2 vCPU's and 4GB of RAM.
 
![Launch on Compute Engine](img/vm_details.png)
![Launch on Compute Engine](img/vm_details.png)
 
1. Click **Change** under Boot disk to select the size, type, and desired operating system. GitLab supports a [variety of linux operating systems][req], including Ubuntu and Debian. Click **Select** when finished.
 
![Deploy in progress](img/boot_disk.png)
![Deploy in progress](img/boot_disk.png)
 
1. As a last step allow HTTP and HTTPS traffic, then click **Create**. The process will finish in a few seconds.
 
@@ -53,13 +53,13 @@ After a few seconds, the instance will be created and available to log in. The n
1. Click on the SSH button to connect to the instance.
1. A new window will appear, with you logged into the instance.
 
![GitLab first sign in](img/ssh_terminal.png)
![GitLab first sign in](img/ssh_terminal.png)
 
1. Next, follow the instructions for installing GitLab for the operating system you choose, at <https://about.gitlab.com/install/>. You can use the IP address from the step above, as the hostname.
 
1. Congratulations! GitLab is now installed and you can access it via your browser. To finish installation, open the URL in your browser and provide the initial administrator password. The username for this account is `root`.
 
![GitLab first sign in](img/first_signin.png)
![GitLab first sign in](img/first_signin.png)
 
## Next steps
 
@@ -83,31 +83,31 @@ here's how you configure GitLab to be aware of the change:
1. SSH into the VM. You can easily use the **SSH** button in the Google console
and a new window will pop up.
 
![SSH button](img/vm_created.png)
![SSH button](img/vm_created.png)
 
In the future you might want to set up [connecting with an SSH key][ssh]
instead.
In the future you might want to set up [connecting with an SSH key][ssh]
instead.
 
1. Edit the config file of Omnibus GitLab using your favorite text editor:
 
```
sudo vim /etc/gitlab/gitlab.rb
```
```
sudo vim /etc/gitlab/gitlab.rb
```
 
1. Set the `external_url` value to the domain name you wish GitLab to have
**without** `https`:
 
```
external_url 'http://gitlab.example.com'
```
```
external_url 'http://gitlab.example.com'
```
 
We will set up HTTPS in the next step, no need to do this now.
We will set up HTTPS in the next step, no need to do this now.
 
1. Reconfigure GitLab for the changes to take effect:
 
```
sudo gitlab-ctl reconfigure
```
```
sudo gitlab-ctl reconfigure
```
 
1. You can now visit GitLab using the domain name.
 
doc/install/installation.md
+ 45
− 44
View file @ 33c867b7
@@ -299,57 +299,57 @@ use of extensions and concurrent index removal, you need at least PostgreSQL 9.2
 
1. Install the database packages:
 
```sh
sudo apt-get install -y postgresql postgresql-client libpq-dev postgresql-contrib
```
```sh
sudo apt-get install -y postgresql postgresql-client libpq-dev postgresql-contrib
```
 
1. Create a database user for GitLab:
 
```sh
sudo -u postgres psql -d template1 -c "CREATE USER git CREATEDB;"
```
```sh
sudo -u postgres psql -d template1 -c "CREATE USER git CREATEDB;"
```
 
1. Create the `pg_trgm` extension (required for GitLab 8.6+):
 
```sh
sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
```
```sh
sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
```
 
1. Create the GitLab production database and grant all privileges on database:
 
```sh
sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"
```
```sh
sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"
```
 
1. Try connecting to the new database with the new user:
 
```sh
sudo -u git -H psql -d gitlabhq_production
```
```sh
sudo -u git -H psql -d gitlabhq_production
```
 
1. Check if the `pg_trgm` extension is enabled:
 
```sh
SELECT true AS enabled
FROM pg_available_extensions
WHERE name = 'pg_trgm'
AND installed_version IS NOT NULL;
```
```sh
SELECT true AS enabled
FROM pg_available_extensions
WHERE name = 'pg_trgm'
AND installed_version IS NOT NULL;
```
 
If the extension is enabled this will produce the following output:
If the extension is enabled this will produce the following output:
 
```
enabled
---------
t
(1 row)
```
```
enabled
---------
t
(1 row)
```
 
1. Quit the database session:
 
```sh
gitlabhq_production> \q
```
```sh
gitlabhq_production> \q
```
 
## 7. Redis
 
@@ -831,26 +831,27 @@ how to configure GitLab with a relative URL.
To use GitLab with HTTPS:
 
1. In `gitlab.yml`:
1. Set the `port` option in section 1 to `443`.
1. Set the `https` option in section 1 to `true`.
1. Set the `port` option in section 1 to `443`.
1. Set the `https` option in section 1 to `true`.
1. In the `config.yml` of gitlab-shell:
1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
1. Set the certificates using either the `ca_file` or `ca_path` option.
1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
1. Set the certificates using either the `ca_file` or `ca_path` option.
1. Use the `gitlab-ssl` Nginx example config instead of the `gitlab` config.
1. Update `YOUR_SERVER_FQDN`.
1. Update `ssl_certificate` and `ssl_certificate_key`.
1. Review the configuration file and consider applying other security and performance enhancing features.
1. Update `YOUR_SERVER_FQDN`.
1. Update `ssl_certificate` and `ssl_certificate_key`.
1. Review the configuration file and consider applying other security and performance enhancing features.
 
Using a self-signed certificate is discouraged but if you must use it, follow the normal directions. Then:
 
1. Generate a self-signed SSL certificate:
 
```sh
mkdir -p /etc/nginx/ssl/
cd /etc/nginx/ssl/
sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
sudo chmod o-r gitlab.key
```
```sh
mkdir -p /etc/nginx/ssl/
cd /etc/nginx/ssl/
sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
sudo chmod o-r gitlab.key
```
1. In the `config.yml` of gitlab-shell set `self_signed_cert` to `true`.
 
### Enable Reply by email
doc/install/openshift_and_gitlab/index.md
+ 50
− 50
View file @ 33c867b7
@@ -70,17 +70,17 @@ In short:
 
1. Open a terminal and in a new directory run:
 
```sh
vagrant init openshift/origin-all-in-one
```
```sh
vagrant init openshift/origin-all-in-one
```
 
1. This will generate a Vagrantfile based on the all-in-one VM image
1. In the same directory where you generated the Vagrantfile
enter:
 
```sh
vagrant up
```
```sh
vagrant up
```
 
This will download the VirtualBox image and fire up the VM with some preconfigured
values as you can see in the Vagrantfile. As you may have noticed, you need
@@ -195,22 +195,22 @@ In that case, the OpenShift service might not be running, so in order to fix it:
1. SSH into the VM by going to the directory where the Vagrantfile is and then
run:
 
```sh
vagrant ssh
```
```sh
vagrant ssh
```
 
1. Run `systemctl` and verify by the output that the `openshift` service is not
running (it will be in red color). If that's the case start the service with:
 
```sh
sudo systemctl start openshift
```
```sh
sudo systemctl start openshift
```
 
1. Verify the service is up with:
 
```sh
systemctl status openshift -l
```
```sh
systemctl status openshift -l
```
 
Now you will be able to login using `oc` (like we did before) and visit the web
console.
@@ -393,55 +393,55 @@ Let's see how to do that using the following steps.
 
1. Make sure you are in the `gitlab` project:
 
```sh
oc project gitlab
```
```sh
oc project gitlab
```
 
1. See what services are used for this project:
 
```sh
oc get svc
```
```sh
oc get svc
```
 
The output will be similar to:
The output will be similar to:
 
```
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gitlab-ce 172.30.243.177 <none> 22/TCP,80/TCP 5d
gitlab-ce-postgresql 172.30.116.75 <none> 5432/TCP 5d
gitlab-ce-redis 172.30.105.88 <none> 6379/TCP 5d
```
```
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gitlab-ce 172.30.243.177 <none> 22/TCP,80/TCP 5d
gitlab-ce-postgresql 172.30.116.75 <none> 5432/TCP 5d
gitlab-ce-redis 172.30.105.88 <none> 6379/TCP 5d
```
 
1. We need to see the replication controllers of the `gitlab-ce` service.
Get a detailed view of the current ones:
 
```sh
oc describe rc gitlab-ce
```
```sh
oc describe rc gitlab-ce
```
 
This will return a large detailed list of the current replication controllers.
Search for the name of the GitLab controller, usually `gitlab-ce-1` or if
that failed at some point and you spawned another one, it will be named
`gitlab-ce-2`.
This will return a large detailed list of the current replication controllers.
Search for the name of the GitLab controller, usually `gitlab-ce-1` or if
that failed at some point and you spawned another one, it will be named
`gitlab-ce-2`.
 
1. Scale GitLab using the previous information:
 
```sh
oc scale --replicas=2 replicationcontrollers gitlab-ce-2
```
```sh
oc scale --replicas=2 replicationcontrollers gitlab-ce-2
```
 
1. Get the new replicas number to make sure scaling worked:
 
```sh
oc get rc gitlab-ce-2
```
```sh
oc get rc gitlab-ce-2
```
 
which will return something like:
which will return something like:
 
```
NAME DESIRED CURRENT AGE
gitlab-ce-2 2 2 5d
```
```
NAME DESIRED CURRENT AGE
gitlab-ce-2 2 2 5d
```
 
And that's it! We successfully scaled the replicas to 2 using the CLI.
 
@@ -478,13 +478,13 @@ For OpenShift v3.0, you will need to do this manually:
 
1. Edit the Security Context:
 
```sh
oc edit scc anyuid
```
```sh
oc edit scc anyuid
```
 
1. Add `system:serviceaccount:<project>:gitlab-ce-user` to the `users` section.
If you changed the Application Name from the default the user will
will be `<app-name>-user` instead of `gitlab-ce-user`
will be `<app-name>-user` instead of `gitlab-ce-user`
 
1. Save and exit the editor
 
doc/install/relative_url.md
+ 41
− 41
View file @ 33c867b7
@@ -58,59 +58,59 @@ assumptions are made:
 
Make sure to follow all steps below:
 
1. (Optional) If you run short on resources, you can temporarily free up some
memory by shutting down the GitLab service with the following command:
1. (Optional) If you run short on resources, you can temporarily free up some
memory by shutting down the GitLab service with the following command:
 
```shell
sudo service gitlab stop
```
```shell
sudo service gitlab stop
```
 
1. Create `/home/git/gitlab/config/initializers/relative_url.rb`
1. Create `/home/git/gitlab/config/initializers/relative_url.rb`
 
```shell
cp /home/git/gitlab/config/initializers/relative_url.rb.sample \
/home/git/gitlab/config/initializers/relative_url.rb
```
```shell
cp /home/git/gitlab/config/initializers/relative_url.rb.sample \
/home/git/gitlab/config/initializers/relative_url.rb
```
 
and change the following line:
and change the following line:
 
```ruby
config.relative_url_root = "/gitlab"
```
```ruby
config.relative_url_root = "/gitlab"
```
 
1. Edit `/home/git/gitlab/config/gitlab.yml` and uncomment/change the
following line:
1. Edit `/home/git/gitlab/config/gitlab.yml` and uncomment/change the
following line:
 
```yaml
relative_url_root: /gitlab
```
```yaml
relative_url_root: /gitlab
```
 
1. Edit `/home/git/gitlab/config/unicorn.rb` and uncomment/change the
following line:
1. Edit `/home/git/gitlab/config/unicorn.rb` and uncomment/change the
following line:
 
```ruby
ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"
```
```ruby
ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"
```
 
1. Edit `/home/git/gitlab-shell/config.yml` and append the relative path to
the following line:
1. Edit `/home/git/gitlab-shell/config.yml` and append the relative path to
the following line:
 
```yaml
gitlab_url: http://127.0.0.1/gitlab
```
```yaml
gitlab_url: http://127.0.0.1/gitlab
```
 
1. Make sure you have copied the supplied init script and the defaults file
as stated in the [installation guide](installation.md#install-init-script).
Then, edit `/etc/default/gitlab` and set in `gitlab_workhorse_options` the
`-authBackend` setting to read like:
1. Make sure you have copied the supplied init script and the defaults file
as stated in the [installation guide](installation.md#install-init-script).
Then, edit `/etc/default/gitlab` and set in `gitlab_workhorse_options` the
`-authBackend` setting to read like:
 
```shell
-authBackend http://127.0.0.1:8080/gitlab
```
```shell
-authBackend http://127.0.0.1:8080/gitlab
```
 
**Note:**
If you are using a custom init script, make sure to edit the above
gitlab-workhorse setting as needed.
**Note:**
If you are using a custom init script, make sure to edit the above
gitlab-workhorse setting as needed.
 
1. [Restart GitLab][] for the changes to take effect.
 
@@ -118,9 +118,9 @@ Make sure to follow all steps below:
 
To disable the relative URL:
 
1. Remove `/home/git/gitlab/config/initializers/relative_url.rb`
1. Remove `/home/git/gitlab/config/initializers/relative_url.rb`
 
1. Follow the same as above starting from 2. and set up the
1. Follow the same as above starting from 2. and set up the
GitLab URL to one that doesn't contain a relative path.
 
[omnibus-rel]: https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-a-relative-url-for-gitlab "How to set up relative URL in Omnibus GitLab"
doc/integration/auth0.md
+ 44
− 44
View file @ 33c867b7
@@ -16,64 +16,64 @@ application.
1. At the top of the Settings screen, you should see your Domain, Client ID and
Client Secret. Take note of these as you'll need to put them in the
configuration file. For example:
- Domain: `test1234.auth0.com`
- Client ID: `t6X8L2465bNePWLOvt9yi41i`
- Client Secret: `KbveM3nqfjwCbrhaUy_gDu2dss8TIlHIdzlyf33pB7dEK5u_NyQdp65O_o02hXs2`
- Domain: `test1234.auth0.com`
- Client ID: `t6X8L2465bNePWLOvt9yi41i`
- Client Secret: `KbveM3nqfjwCbrhaUy_gDu2dss8TIlHIdzlyf33pB7dEK5u_NyQdp65O_o02hXs2`
 
1. Fill in the Allowed Callback URLs:
- `http://YOUR_GITLAB_URL/users/auth/auth0/callback` (or)
- `https://YOUR_GITLAB_URL/users/auth/auth0/callback`
- `http://YOUR_GITLAB_URL/users/auth/auth0/callback` (or)
- `https://YOUR_GITLAB_URL/users/auth/auth0/callback`
 
1. Fill in the Allowed Origins (CORS):
- `http://YOUR_GITLAB_URL` (or)
- `https://YOUR_GITLAB_URL`
- `http://YOUR_GITLAB_URL` (or)
- `https://YOUR_GITLAB_URL`
 
1. On your GitLab server, open the configuration file.
 
For omnibus package:
For omnibus package:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
for initial settings.
 
1. Add the provider configuration:
 
For omnibus package:
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "auth0",
"args" => { client_id: 'YOUR_AUTH0_CLIENT_ID',
client_secret: 'YOUR_AUTH0_CLIENT_SECRET',
domain: 'YOUR_AUTH0_DOMAIN',
scope: 'openid profile email'
}
}
]
```
For installations from source:
```yaml
- { name: 'auth0',
args: {
client_id: 'YOUR_AUTH0_CLIENT_ID',
client_secret: 'YOUR_AUTH0_CLIENT_SECRET',
domain: 'YOUR_AUTH0_DOMAIN',
scope: 'openid profile email' }
}
```
For omnibus package:
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "auth0",
"args" => { client_id: 'YOUR_AUTH0_CLIENT_ID',
client_secret: 'YOUR_AUTH0_CLIENT_SECRET',
domain: 'YOUR_AUTH0_DOMAIN',
scope: 'openid profile email'
}
}
]
```
For installations from source:
```yaml
- { name: 'auth0',
args: {
client_id: 'YOUR_AUTH0_CLIENT_ID',
client_secret: 'YOUR_AUTH0_CLIENT_SECRET',
domain: 'YOUR_AUTH0_DOMAIN',
scope: 'openid profile email' }
}
```
 
1. Change `YOUR_AUTH0_CLIENT_ID` to the client ID from the Auth0 Console page
from step 5.
@@ -81,8 +81,8 @@ application.
1. Change `YOUR_AUTH0_CLIENT_SECRET` to the client secret from the Auth0 Console
page from step 5.
 
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
 
On the sign in page there should now be an Auth0 icon below the regular sign in
form. Click the icon to begin the authentication process. Auth0 will ask the
doc/integration/bitbucket.md
+ 91
− 91
View file @ 33c867b7
@@ -30,97 +30,97 @@ To enable the Bitbucket OmniAuth provider you must register your application
with Bitbucket.org. Bitbucket will generate an application ID and secret key for
you to use.
 
1. Sign in to [Bitbucket.org](https://bitbucket.org).
1. Navigate to your individual user settings (**Bitbucket settings**) or a team's
settings (**Manage team**), depending on how you want the application registered.
It does not matter if the application is registered as an individual or a
team, that is entirely up to you.
1. Select **OAuth** in the left menu under "Access Management".
1. Select **Add consumer**.
1. Provide the required details:
| Item | Description |
| :--- | :---------- |
| **Name** | This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive. |
| **Application description** | Fill this in if you wish. |
| **Callback URL** | The URL to your GitLab installation, e.g., `https://gitlab.example.com/users/auth`. |
| **URL** | The URL to your GitLab installation, e.g., `https://gitlab.example.com`. |
NOTE: Be sure to append `/users/auth` to the end of the callback URL
to prevent a [OAuth2 convert
redirect](http://tetraph.com/covert_redirect/) vulnerability.
NOTE: Starting in GitLab 8.15, you MUST specify a callback URL, or you will
see an "Invalid redirect_uri" message. For more details, see [the
Bitbucket documentation](https://confluence.atlassian.com/bitbucket/oauth-faq-338365710.html).
And grant at least the following permissions:
```
Account: Email, Read
Projects: Read
Repositories: Read
Pull Requests: Read
Issues: Read
Wiki: Read and Write
```
![Bitbucket OAuth settings page](img/bitbucket_oauth_settings_page.png)
1. Select **Save**.
1. Select your newly created OAuth consumer and you should now see a Key and
Secret in the list of OAuth consumers. Keep this page open as you continue
the configuration.
![Bitbucket OAuth key](img/bitbucket_oauth_keys.png)
1. On your GitLab server, open the configuration file:
```
# For Omnibus packages
sudo editor /etc/gitlab/gitlab.rb
# For installations from source
sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
```
1. Add the Bitbucket provider configuration:
For Omnibus packages:
```ruby
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [
{
"name" => "bitbucket",
"app_id" => "BITBUCKET_APP_KEY",
"app_secret" => "BITBUCKET_APP_SECRET",
"url" => "https://bitbucket.org/"
}
]
```
For installations from source:
```yaml
omniauth:
enabled: true
providers:
- { name: 'bitbucket',
app_id: 'BITBUCKET_APP_KEY',
app_secret: 'BITBUCKET_APP_SECRET',
url: 'https://bitbucket.org/' }
```
---
Where `BITBUCKET_APP_KEY` is the Key and `BITBUCKET_APP_SECRET` the Secret
from the Bitbucket application page.
1. Save the configuration file.
1. For the changes to take effect, [reconfigure GitLab][] if you installed via
Omnibus, or [restart][] if installed from source.
1. Sign in to [Bitbucket.org](https://bitbucket.org).
1. Navigate to your individual user settings (**Bitbucket settings**) or a team's
settings (**Manage team**), depending on how you want the application registered.
It does not matter if the application is registered as an individual or a
team, that is entirely up to you.
1. Select **OAuth** in the left menu under "Access Management".
1. Select **Add consumer**.
1. Provide the required details:
| Item | Description |
| :--- | :---------- |
| **Name** | This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive. |
| **Application description** | Fill this in if you wish. |
| **Callback URL** | The URL to your GitLab installation, e.g., `https://gitlab.example.com/users/auth`. |
| **URL** | The URL to your GitLab installation, e.g., `https://gitlab.example.com`. |
NOTE: Be sure to append `/users/auth` to the end of the callback URL
to prevent a [OAuth2 convert
redirect](http://tetraph.com/covert_redirect/) vulnerability.
NOTE: Starting in GitLab 8.15, you MUST specify a callback URL, or you will
see an "Invalid redirect_uri" message. For more details, see [the
Bitbucket documentation](https://confluence.atlassian.com/bitbucket/oauth-faq-338365710.html).
And grant at least the following permissions:
```
Account: Email, Read
Projects: Read
Repositories: Read
Pull Requests: Read
Issues: Read
Wiki: Read and Write
```
![Bitbucket OAuth settings page](img/bitbucket_oauth_settings_page.png)
1. Select **Save**.
1. Select your newly created OAuth consumer and you should now see a Key and
Secret in the list of OAuth consumers. Keep this page open as you continue
the configuration.
![Bitbucket OAuth key](img/bitbucket_oauth_keys.png)
1. On your GitLab server, open the configuration file:
```
# For Omnibus packages
sudo editor /etc/gitlab/gitlab.rb
# For installations from source
sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
```
1. Add the Bitbucket provider configuration:
For Omnibus packages:
```ruby
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [
{
"name" => "bitbucket",
"app_id" => "BITBUCKET_APP_KEY",
"app_secret" => "BITBUCKET_APP_SECRET",
"url" => "https://bitbucket.org/"
}
]
```
For installations from source:
```yaml
omniauth:
enabled: true
providers:
- { name: 'bitbucket',
app_id: 'BITBUCKET_APP_KEY',
app_secret: 'BITBUCKET_APP_SECRET',
url: 'https://bitbucket.org/' }
```
---
Where `BITBUCKET_APP_KEY` is the Key and `BITBUCKET_APP_SECRET` the Secret
from the Bitbucket application page.
1. Save the configuration file.
1. For the changes to take effect, [reconfigure GitLab][] if you installed via
Omnibus, or [restart][] if installed from source.
 
On the sign in page there should now be a Bitbucket icon below the regular sign
in form. Click the icon to begin the authentication process. Bitbucket will ask
doc/integration/cas.md
+ 42
− 42
View file @ 33c867b7
@@ -2,63 +2,63 @@
 
To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout.
 
1. On your GitLab server, open the configuration file.
1. On your GitLab server, open the configuration file.
 
For omnibus package:
For omnibus package:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
```sh
cd /home/git/gitlab
 
sudo -u git -H editor config/gitlab.yml
```
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
1. Add the provider configuration:
1. Add the provider configuration:
 
For omnibus package:
For omnibus package:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name"=> "cas3",
"label"=> "cas",
"args"=> {
"url"=> 'CAS_SERVER',
"login_url"=> '/CAS_PATH/login',
"service_validate_url"=> '/CAS_PATH/p3/serviceValidate',
"logout_url"=> '/CAS_PATH/logout'
}
}
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name"=> "cas3",
"label"=> "cas",
"args"=> {
"url"=> 'CAS_SERVER',
"login_url"=> '/CAS_PATH/login',
"service_validate_url"=> '/CAS_PATH/p3/serviceValidate',
"logout_url"=> '/CAS_PATH/logout'
}
}
]
```
 
For installations from source:
For installations from source:
 
```
- { name: 'cas3',
label: 'cas',
args: {
url: 'CAS_SERVER',
login_url: '/CAS_PATH/login',
service_validate_url: '/CAS_PATH/p3/serviceValidate',
logout_url: '/CAS_PATH/logout'} }
```
```
- { name: 'cas3',
label: 'cas',
args: {
url: 'CAS_SERVER',
login_url: '/CAS_PATH/login',
service_validate_url: '/CAS_PATH/p3/serviceValidate',
logout_url: '/CAS_PATH/logout'} }
```
 
1. Change 'CAS_PATH' to the root of your CAS instance (ie. `cas`).
1. Change 'CAS_PATH' to the root of your CAS instance (ie. `cas`).
 
1. If your CAS instance does not use default TGC lifetimes, update the `cas3.session_duration` to at least the current TGC maximum lifetime. To explicitly disable SLO, regardless of CAS settings, set this to 0.
1. If your CAS instance does not use default TGC lifetimes, update the `cas3.session_duration` to at least the current TGC maximum lifetime. To explicitly disable SLO, regardless of CAS settings, set this to 0.
 
1. Save the configuration file.
1. Save the configuration file.
 
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
 
On the sign in page there should now be a CAS tab in the sign in form.
 
doc/integration/elasticsearch.md
+ 56
− 56
View file @ 33c867b7
@@ -12,6 +12,7 @@ special searches:
- [Advanced Syntax Search](../user/search/advanced_search_syntax.md)
 
## Version Requirements
<!-- Please remember to update ee/lib/system_check/app/elasticsearch_check.rb if this changes -->
 
| GitLab version | Elasticsearch version |
@@ -424,91 +425,90 @@ Here are some common pitfalls and how to overcome them:
 
- **How can I verify my GitLab instance is using Elasticsearch?**
 
The easiest method is via the rails console (`sudo gitlab-rails console`) by running the following:
The easiest method is via the rails console (`sudo gitlab-rails console`) by running the following:
 
```ruby
u = User.find_by_username('your-username')
s = SearchService.new(u, {:search => 'search_term'})
pp s.search_objects.class.name
```
```ruby
u = User.find_by_username('your-username')
s = SearchService.new(u, {:search => 'search_term'})
pp s.search_objects.class.name
```
 
If you see `Elasticsearch::Model::Response::Records`, you are using Elasticsearch.
If you see `Elasticsearch::Model::Response::Records`, you are using Elasticsearch.
 
- **I updated GitLab and now I can't find anything**
 
We continuously make updates to our indexing strategies and aim to support
newer versions of Elasticsearch. When indexing changes are made, it may
be necessary for you to [reindex](#adding-gitlabs-data-to-the-elasticsearch-index) after updating GitLab.
We continuously make updates to our indexing strategies and aim to support
newer versions of Elasticsearch. When indexing changes are made, it may
be necessary for you to [reindex](#adding-gitlabs-data-to-the-elasticsearch-index) after updating GitLab.
 
- **I indexed all the repositories but I can't find anything**
 
Make sure you indexed all the database data [as stated above](#adding-gitlabs-data-to-the-elasticsearch-index).
Make sure you indexed all the database data [as stated above](#adding-gitlabs-data-to-the-elasticsearch-index).
 
Beyond that, check via the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) to see if the data shows up on the Elasticsearch side.
Beyond that, check via the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) to see if the data shows up on the Elasticsearch side.
 
If it shows up via the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html), check that it shows up via the rails console (`sudo gitlab-rails console`):
If it shows up via the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html), check that it shows up via the rails console (`sudo gitlab-rails console`):
 
```ruby
u = User.find_by_username('your-username')
s = SearchService.new(u, {:search => 'search_term', :scope => ‘blobs’})
pp s.search_objects.to_a
```
```ruby
u = User.find_by_username('your-username')
s = SearchService.new(u, {:search => 'search_term', :scope => ‘blobs’})
pp s.search_objects.to_a
```
 
See [Elasticsearch Index Scopes](elasticsearch.md#elasticsearch-index-scopes) for more information on searching for specific types of data.
See [Elasticsearch Index Scopes](elasticsearch.md#elasticsearch-index-scopes) for more information on searching for specific types of data.
 
- **I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything**
 
You will need to re-run all the rake tasks to re-index the database, repositories, and wikis.
You will need to re-run all the rake tasks to re-index the database, repositories, and wikis.
 
- **The indexing process is taking a very long time**
 
The more data present in your GitLab instance, the longer the indexing process takes.
The more data present in your GitLab instance, the longer the indexing process takes.
 
- **No new data is added to the Elasticsearch index when I push code**
 
When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could
happen that an error during the process causes one or multiple projects to remain locked. In order to unlock them,
run the `gitlab:elastic:clear_locked_projects` rake task.
When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could
happen that an error during the process causes one or multiple projects to remain locked. In order to unlock them,
run the `gitlab:elastic:clear_locked_projects` rake task.
 
- **"Can't specify parent if no parent field has been configured"**
 
If you enabled Elasticsearch before GitLab 8.12 and have not rebuilt indexes you will get
exception in lots of different cases:
```text
Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
"error": {
"root_cause": [{
"type": "illegal_argument_exception",
"reason": "Can't specify parent if no parent field has been configured"
}],
"type": "illegal_argument_exception",
"reason": "Can't specify parent if no parent field has been configured"
},
"status": 400
}):
```
This is because we changed the index mapping in GitLab 8.12 and the old indexes should be removed and built from scratch again,
see details in the [8-11-to-8-12 update guide](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/update/8.11-to-8.12.md#11-elasticsearch-index-update-if-you-currently-use-elasticsearch).
If you enabled Elasticsearch before GitLab 8.12 and have not rebuilt indexes you will get
exception in lots of different cases:
```text
Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
"error": {
"root_cause": [{
"type": "illegal_argument_exception",
"reason": "Can't specify parent if no parent field has been configured"
}],
"type": "illegal_argument_exception",
"reason": "Can't specify parent if no parent field has been configured"
},
"status": 400
}):
```
This is because we changed the index mapping in GitLab 8.12 and the old indexes should be removed and built from scratch again,
see details in the [8-11-to-8-12 update guide](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/update/8.11-to-8.12.md#11-elasticsearch-index-update-if-you-currently-use-elasticsearch).
 
- Exception `Elasticsearch::Transport::Transport::Errors::BadRequest`
 
If you have this exception (just like in the case above but the actual message is different) please check if you have the correct Elasticsearch version and you met the other [requirements](#system-requirements).
There is also an easy way to check it automatically with `sudo gitlab-rake gitlab:check` command.
If you have this exception (just like in the case above but the actual message is different) please check if you have the correct Elasticsearch version and you met the other [requirements](#system-requirements).
There is also an easy way to check it automatically with `sudo gitlab-rake gitlab:check` command.
 
- Exception `Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge`
 
```text
[413] {"Message":"Request size exceeded 10485760 bytes"}
```
This exception is seen when your Elasticsearch cluster is configured to reject
requests above a certain size (10MiB in this case). This corresponds to the
`http.max_content_length` setting in `elasticsearch.yml`. Increase it to a
larger size and restart your Elasticsearch cluster.
```text
[413] {"Message":"Request size exceeded 10485760 bytes"}
```
 
AWS has [fixed limits](http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
the underlying instance.
This exception is seen when your Elasticsearch cluster is configured to reject
requests above a certain size (10MiB in this case). This corresponds to the
`http.max_content_length` setting in `elasticsearch.yml`. Increase it to a
larger size and restart your Elasticsearch cluster.
 
AWS has [fixed limits](http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
the underlying instance.
doc/integration/facebook.md
+ 33
− 33
View file @ 33c867b7
@@ -2,7 +2,7 @@
 
To enable the Facebook OmniAuth provider you must register your application with Facebook. Facebook will generate an app ID and secret key for you to use.
 
1. Sign in to the [Facebook Developer Platform](https://developers.facebook.com/).
1. Sign in to the [Facebook Developer Platform](https://developers.facebook.com/).
 
1. Choose "My Apps" &gt; "Add a New App"
 
@@ -47,53 +47,53 @@ To enable the Facebook OmniAuth provider you must register your application with
 
![Facebook API Keys](img/facebook_api_keys.png)
 
1. On your GitLab server, open the configuration file.
1. On your GitLab server, open the configuration file.
 
For omnibus package:
For omnibus package:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
```sh
cd /home/git/gitlab
 
sudo -u git -H editor config/gitlab.yml
```
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
1. Add the provider configuration:
1. Add the provider configuration:
 
For omnibus package:
For omnibus package:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "facebook",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET"
}
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "facebook",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET"
}
]
```
 
For installations from source:
For installations from source:
 
```
- { name: 'facebook', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET' }
```
```
- { name: 'facebook', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET' }
```
 
1. Change 'YOUR_APP_ID' to the API key from Facebook page in step 10.
1. Change 'YOUR_APP_ID' to the API key from Facebook page in step 10.
 
1. Change 'YOUR_APP_SECRET' to the API secret from the Facebook page in step 10.
1. Change 'YOUR_APP_SECRET' to the API secret from the Facebook page in step 10.
 
1. Save the configuration file.
1. Save the configuration file.
 
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
 
On the sign in page there should now be a Facebook icon below the regular sign in form. Click the icon to begin the authentication process. Facebook will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
 
doc/integration/github.md
+ 90
− 90
View file @ 33c867b7
@@ -7,111 +7,111 @@ You can integrate your GitLab instance with GitHub.com as well as GitHub Enterpr
To enable GitHub OmniAuth provider, you must use GitHub's credentials for your GitLab instance.
To get the credentials (a pair of Client ID and Client Secret), you must register an application as an OAuth App on GitHub.
 
1. Sign in to GitHub.
1. Sign in to GitHub.
 
1. Navigate to your individual user or organization settings, depending on how you want the application registered. It does not matter if the application is registered as an individual or an organization - that is entirely up to you.
1. Navigate to your individual user or organization settings, depending on how you want the application registered. It does not matter if the application is registered as an individual or an organization - that is entirely up to you.
 
- For individual accounts, select **Developer settings** from the left menu, then select **OAuth Apps**.
- For organization accounts, directly select **OAuth Apps** from the left menu.
- For individual accounts, select **Developer settings** from the left menu, then select **OAuth Apps**.
- For organization accounts, directly select **OAuth Apps** from the left menu.
 
1. Select **Register an application** (if you don't have any OAuth App) or **New OAuth App** (if you already have OAuth Apps).
![Register OAuth App](img/github_app_entry.png)
1. Select **Register an application** (if you don't have any OAuth App) or **New OAuth App** (if you already have OAuth Apps).
![Register OAuth App](img/github_app_entry.png)
 
1. Provide the required details.
- Application name: This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive.
- Homepage URL: The URL of your GitLab installation. For example, `https://gitlab.example.com`.
- Application description: Fill this in if you wish.
- Authorization callback URL: `http(s)://${YOUR_DOMAIN}/users/auth`. Please make sure the port is included if your GitLab instance is not configured on default port.
![Register OAuth App](img/github_register_app.png)
1. Provide the required details.
- Application name: This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive.
- Homepage URL: The URL of your GitLab installation. For example, `https://gitlab.example.com`.
- Application description: Fill this in if you wish.
- Authorization callback URL: `http(s)://${YOUR_DOMAIN}/users/auth`. Please make sure the port is included if your GitLab instance is not configured on default port.
![Register OAuth App](img/github_register_app.png)
 
NOTE: Be sure to append `/users/auth` to the end of the callback URL
to prevent a [OAuth2 convert
redirect](http://tetraph.com/covert_redirect/) vulnerability.
NOTE: Be sure to append `/users/auth` to the end of the callback URL
to prevent a [OAuth2 convert
redirect](http://tetraph.com/covert_redirect/) vulnerability.
 
1. Select **Register application**.
1. Select **Register application**.
 
1. You should now see a pair of **Client ID** and **Client Secret** near the top right of the page (see screenshot).
Keep this page open as you continue configuration.
![GitHub app](img/github_app.png)
1. You should now see a pair of **Client ID** and **Client Secret** near the top right of the page (see screenshot).
Keep this page open as you continue configuration.
![GitHub app](img/github_app.png)
 
1. On your GitLab server, open the configuration file.
1. On your GitLab server, open the configuration file.
 
For omnibus package:
For omnibus package:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
```sh
cd /home/git/gitlab
 
sudo -u git -H editor config/gitlab.yml
```
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
1. Add the provider configuration:
1. Add the provider configuration:
 
For omnibus package:
For omnibus package:
 
For GitHub.com:
For GitHub.com:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "github",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"args" => { "scope" => "user:email" }
}
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "github",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"args" => { "scope" => "user:email" }
}
]
```
 
For GitHub Enterprise:
For GitHub Enterprise:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "github",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"url" => "https://github.example.com/",
"args" => { "scope" => "user:email" }
}
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "github",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"url" => "https://github.example.com/",
"args" => { "scope" => "user:email" }
}
]
```
 
For installation from source:
For installation from source:
 
For GitHub.com:
For GitHub.com:
 
```
- { name: 'github', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
args: { scope: 'user:email' } }
```
```
- { name: 'github', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
args: { scope: 'user:email' } }
```
 
For GitHub Enterprise:
For GitHub Enterprise:
 
```
- { name: 'github', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
url: "https://github.example.com/",
args: { scope: 'user:email' } }
```
```
- { name: 'github', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
url: "https://github.example.com/",
args: { scope: 'user:email' } }
```
 
__Replace `https://github.example.com/` with your GitHub URL.__
__Replace `https://github.example.com/` with your GitHub URL.__
 
1. Change `YOUR_APP_ID` to the Client ID from the GitHub application page from step 6.
1. Change `YOUR_APP_ID` to the Client ID from the GitHub application page from step 6.
 
1. Change `YOUR_APP_SECRET` to the Client Secret from the GitHub application page from step 6.
1. Change `YOUR_APP_SECRET` to the Client Secret from the GitHub application page from step 6.
 
1. Save the configuration file.
1. Save the configuration file.
 
1. [Reconfigure GitLab][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
1. [Reconfigure GitLab][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
 
On the sign in page there should now be a GitHub icon below the regular sign in form.
Click the icon to begin the authentication process. GitHub will ask the user to sign in and authorize the GitLab application.
@@ -127,16 +127,16 @@ and changing the global Git `sslVerify` option to `false` in the GitLab server.
For omnibus package:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "github",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"url" => "https://github.example.com/",
"verify_ssl" => false,
"args" => { "scope" => "user:email" }
}
]
gitlab_rails['omniauth_providers'] = [
{
"name" => "github",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"url" => "https://github.example.com/",
"verify_ssl" => false,
"args" => { "scope" => "user:email" }
}
]
```
 
You will also need to disable Git SSL verification on the server hosting GitLab.
@@ -148,11 +148,11 @@ omnibus_gitconfig['system'] = { "http" => ["sslVerify = false"] }
For installation from source:
 
```
- { name: 'github', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
url: "https://github.example.com/",
verify_ssl: false,
args: { scope: 'user:email' } }
- { name: 'github', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
url: "https://github.example.com/",
verify_ssl: false,
args: { scope: 'user:email' } }
```
 
You will also need to disable Git SSL verification on the server hosting GitLab.
doc/integration/gitlab.md
+ 48
− 48
View file @ 33c867b7
@@ -5,78 +5,78 @@ Import projects from GitLab.com and login to your GitLab instance with your GitL
To enable the GitLab.com OmniAuth provider you must register your application with GitLab.com.
GitLab.com will generate an application ID and secret key for you to use.
 
1. Sign in to GitLab.com
1. Sign in to GitLab.com
 
1. On the upper right corner, click on your avatar and go to your **Settings**.
 
1. Select **Applications** in the left menu.
1. Select **Applications** in the left menu.
 
1. Provide the required details for **Add new application**.
- Name: This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive.
- Redirect URI:
1. Provide the required details for **Add new application**.
- Name: This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive.
- Redirect URI:
 
```
http://your-gitlab.example.com/import/gitlab/callback
http://your-gitlab.example.com/users/auth/gitlab/callback
```
```
http://your-gitlab.example.com/import/gitlab/callback
http://your-gitlab.example.com/users/auth/gitlab/callback
```
 
The first link is required for the importer and second for the authorization.
The first link is required for the importer and second for the authorization.
 
1. Select **Save application**.
1. Select **Save application**.
 
1. You should now see a **Application Id** and **Secret** near the top right of the page (see screenshot).
Keep this page open as you continue configuration.
![GitLab app](img/gitlab_app.png)
1. You should now see a **Application Id** and **Secret** near the top right of the page (see screenshot).
Keep this page open as you continue configuration.
![GitLab app](img/gitlab_app.png)
 
1. On your GitLab server, open the configuration file.
1. On your GitLab server, open the configuration file.
 
For omnibus package:
For omnibus package:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
```sh
cd /home/git/gitlab
 
sudo -u git -H editor config/gitlab.yml
```
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
1. Add the provider configuration:
1. Add the provider configuration:
 
For omnibus package:
For omnibus package:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "gitlab",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"args" => { "scope" => "api" }
}
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "gitlab",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"args" => { "scope" => "api" }
}
]
```
 
For installations from source:
For installations from source:
 
```
- { name: 'gitlab', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
args: { scope: 'api' } }
```
```
- { name: 'gitlab', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
args: { scope: 'api' } }
```
 
1. Change 'YOUR_APP_ID' to the Application ID from the GitLab.com application page.
1. Change 'YOUR_APP_ID' to the Application ID from the GitLab.com application page.
 
1. Change 'YOUR_APP_SECRET' to the secret from the GitLab.com application page.
1. Change 'YOUR_APP_SECRET' to the secret from the GitLab.com application page.
 
1. Save the configuration file.
1. Save the configuration file.
 
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
 
On the sign in page there should now be a GitLab.com icon below the regular sign in form.
Click the icon to begin the authentication process. GitLab.com will ask the user to sign in and authorize the GitLab application.
doc/integration/google.md
+ 53
− 53
View file @ 33c867b7
@@ -10,10 +10,10 @@ In Google's side:
1. Navigate to the [cloud resource manager](https://console.cloud.google.com/cloud-resource-manager) page
1. Select **Create Project**
1. Provide the project information:
- **Project name** - "GitLab" works just fine here.
- **Project ID** - Must be unique to all Google Developer registered applications.
Google provides a randomly generated Project ID by default. You can use
the randomly generated ID or choose a new one.
- **Project name** - "GitLab" works just fine here.
- **Project ID** - Must be unique to all Google Developer registered applications.
Google provides a randomly generated Project ID by default. You can use
the randomly generated ID or choose a new one.
1. Refresh the page and you should see your new project in the list
1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard)
1. Select the previously created project form the upper left corner
@@ -21,17 +21,17 @@ In Google's side:
1. Select **OAuth consent screen** and fill the form with the required information
1. In the **Credentials** tab, select **Create credentials > OAuth client ID**
1. Fill in the required information
- **Application type** - Choose "Web Application"
- **Name** - Use the default one or provide your own
- **Authorized JavaScript origins** -This isn't really used by GitLab but go
ahead and put `https://gitlab.example.com`
- **Authorized redirect URIs** - Enter your domain name followed by the
callback URIs one at a time:
```
https://gitlab.example.com/users/auth/google_oauth2/callback
https://gitlab.example.com/-/google_api/auth/callback
```
- **Application type** - Choose "Web Application"
- **Name** - Use the default one or provide your own
- **Authorized JavaScript origins** -This isn't really used by GitLab but go
ahead and put `https://gitlab.example.com`
- **Authorized redirect URIs** - Enter your domain name followed by the
callback URIs one at a time:
```
https://gitlab.example.com/users/auth/google_oauth2/callback
https://gitlab.example.com/-/google_api/auth/callback
```
 
1. You should now be able to see a Client ID and Client secret. Note them down
or keep this page open as you will need them later.
@@ -45,64 +45,64 @@ On your GitLab server:
 
1. Open the configuration file.
 
For Omnibus GitLab:
For Omnibus GitLab:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. Add the provider configuration:
 
For Omnibus GitLab:
For Omnibus GitLab:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "google_oauth2",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"args" => { "access_type" => "offline", "approval_prompt" => '' }
}
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "google_oauth2",
"app_id" => "YOUR_APP_ID",
"app_secret" => "YOUR_APP_SECRET",
"args" => { "access_type" => "offline", "approval_prompt" => '' }
}
]
```
 
For installations from source:
For installations from source:
 
```yaml
- { name: 'google_oauth2', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
args: { access_type: 'offline', approval_prompt: '' } }
```
```yaml
- { name: 'google_oauth2', app_id: 'YOUR_APP_ID',
app_secret: 'YOUR_APP_SECRET',
args: { access_type: 'offline', approval_prompt: '' } }
```
 
1. Change `YOUR_APP_ID` to the client ID from the Google Developer page
1. Similarly, change `YOUR_APP_SECRET` to the client secret
1. Make sure that you configure GitLab to use an FQDN as Google will not accept
raw IP addresses.
 
For Omnibus packages:
For Omnibus packages:
 
```ruby
external_url 'https://gitlab.example.com'
```
```ruby
external_url 'https://gitlab.example.com'
```
 
For installations from source:
For installations from source:
 
```yaml
gitlab:
host: https://gitlab.example.com
```
```yaml
gitlab:
host: https://gitlab.example.com
```
 
1. Save the configuration file.
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
1. Save the configuration file.
1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
 
On the sign in page there should now be a Google icon below the regular sign in
form. Click the icon to begin the authentication process. Google will ask the
doc/integration/kerberos.md
+ 52
− 52
View file @ 33c867b7
@@ -50,20 +50,20 @@ For source installations, make sure the `kerberos` gem group
authentication. In most cases, you only need to enable Kerberos and specify
the location of the keytab:
 
```yaml
omniauth:
enabled: true
allow_single_sign_on: ['kerberos']
```yaml
omniauth:
enabled: true
allow_single_sign_on: ['kerberos']
 
kerberos:
# Allow the HTTP Negotiate authentication method for Git clients
enabled: true
kerberos:
# Allow the HTTP Negotiate authentication method for Git clients
enabled: true
 
# Kerberos 5 keytab file. The keytab file must be readable by the GitLab user,
# and should be different from other keytabs in the system.
# (default: use default keytab from Krb5 config)
keytab: /etc/http.keytab
```
# Kerberos 5 keytab file. The keytab file must be readable by the GitLab user,
# and should be different from other keytabs in the system.
# (default: use default keytab from Krb5 config)
keytab: /etc/http.keytab
```
 
1. [Restart GitLab] for the changes to take effect.
 
@@ -73,13 +73,13 @@ For source installations, make sure the `kerberos` gem group
 
1. Edit `/etc/gitlab/gitlab.rb`:
 
```ruby
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['kerberos']
```ruby
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['kerberos']
 
gitlab_rails['kerberos_enabled'] = true
gitlab_rails['kerberos_keytab'] = "/etc/http.keytab"
```
gitlab_rails['kerberos_enabled'] = true
gitlab_rails['kerberos_keytab'] = "/etc/http.keytab"
```
 
1. [Reconfigure GitLab] for the changes to take effect.
 
@@ -149,26 +149,26 @@ keep offering only `basic` authentication.
(e.g., `/etc/nginx/sites-available/gitlab-ssl`) and configure NGINX to
listen to port `8443` in addition to the standard HTTPS port:
 
```conf
server {
listen 0.0.0.0:443 ssl;
listen [::]:443 ipv6only=on ssl default_server;
listen 0.0.0.0:8443 ssl;
listen [::]:8443 ipv6only=on ssl;
```
```conf
server {
listen 0.0.0.0:443 ssl;
listen [::]:443 ipv6only=on ssl default_server;
listen 0.0.0.0:8443 ssl;
listen [::]:8443 ipv6only=on ssl;
```
 
1. Update the Kerberos section of [gitlab.yml]:
 
```yaml
kerberos:
# Dedicated port: Git before 2.4 does not fall back to Basic authentication if Negotiate fails.
# To support both Basic and Negotiate methods with older versions of Git, configure
# nginx to proxy GitLab on an extra port (e.g. 8443) and uncomment the following lines
# to dedicate this port to Kerberos authentication. (default: false)
use_dedicated_port: true
port: 8443
https: true
```
```yaml
kerberos:
# Dedicated port: Git before 2.4 does not fall back to Basic authentication if Negotiate fails.
# To support both Basic and Negotiate methods with older versions of Git, configure
# nginx to proxy GitLab on an extra port (e.g. 8443) and uncomment the following lines
# to dedicate this port to Kerberos authentication. (default: false)
use_dedicated_port: true
port: 8443
https: true
```
 
1. [Restart GitLab] and NGINX for the changes to take effect.
 
@@ -178,11 +178,11 @@ keep offering only `basic` authentication.
 
1. Edit `/etc/gitlab/gitlab.rb`:
 
```ruby
gitlab_rails['kerberos_use_dedicated_port'] = true
gitlab_rails['kerberos_port'] = 8443
gitlab_rails['kerberos_https'] = true
```
```ruby
gitlab_rails['kerberos_use_dedicated_port'] = true
gitlab_rails['kerberos_port'] = 8443
gitlab_rails['kerberos_https'] = true
```
 
1. [Reconfigure GitLab] for the changes to take effect.
 
@@ -214,12 +214,12 @@ remove the OmniAuth provider named `kerberos` from your `gitlab.yml` /
1. Edit [gitlab.yml] and remove the `- { name: 'kerberos' }` line under omniauth
providers:
 
```yaml
omniauth:
# ...
providers:
- { name: 'kerberos' } # <-- remove this line
```
```yaml
omniauth:
# ...
providers:
- { name: 'kerberos' } # <-- remove this line
```
 
1. [Restart GitLab] for the changes to take effect.
 
@@ -230,11 +230,11 @@ remove the OmniAuth provider named `kerberos` from your `gitlab.yml` /
1. Edit `/etc/gitlab/gitlab.rb` and remove the `{ "name" => "kerberos" }` line
under `gitlab_rails['omniauth_providers']`:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{ "name" => "kerberos" } # <-- remove this entry
]
```
```ruby
gitlab_rails['omniauth_providers'] = [
{ "name" => "kerberos" } # <-- remove this entry
]
```
 
1. [Reconfigure GitLab] for the changes to take effect.
 
@@ -290,7 +290,7 @@ remote: HTTP Basic: Access denied
fatal: Authentication failed for '<KRB5 path>'
```
 
If you are using Git v2.11 or newer and see the above error when cloning, you can
If you are using Git v2.11 or newer and see the above error when cloning, you can
set the `http.emptyAuth` Git option to `true` to fix this:
 
```
doc/integration/oauth2_generic.md
+ 13
− 13
View file @ 33c867b7
@@ -24,11 +24,11 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
 
1. Register your application in the OAuth2 provider you wish to authenticate with.
 
The redirect URI you provide when registering the application should be:
The redirect URI you provide when registering the application should be:
 
```
http://your-gitlab.host.com/users/auth/oauth2_generic/callback
```
```
http://your-gitlab.host.com/users/auth/oauth2_generic/callback
```
 
1. You should now be able to get a Client ID and Client Secret.
Where this shows up will differ for each provider.
@@ -36,18 +36,18 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
 
1. On your GitLab server, open the configuration file.
 
For Omnibus package:
For Omnibus package:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For installations from source:
For installations from source:
 
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings
 
doc/integration/omniauth.md
+ 65
− 57
View file @ 33c867b7
@@ -71,57 +71,57 @@ To change these settings:
 
- **For omnibus package**
 
Open the configuration file:
Open the configuration file:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
and change:
and change:
 
```ruby
# Versions prior to 11.4 require this to be set to true
# gitlab_rails['omniauth_enabled'] = nil
```ruby
# Versions prior to 11.4 require this to be set to true
# gitlab_rails['omniauth_enabled'] = nil
 
# CAUTION!
# This allows users to login without having a user account first. Define the allowed providers
# using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter']
gitlab_rails['omniauth_auto_link_ldap_user'] = true
gitlab_rails['omniauth_block_auto_created_users'] = true
```
# CAUTION!
# This allows users to login without having a user account first. Define the allowed providers
# using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter']
gitlab_rails['omniauth_auto_link_ldap_user'] = true
gitlab_rails['omniauth_block_auto_created_users'] = true
```
 
- **For installations from source**
 
Open the configuration file:
Open the configuration file:
 
```sh
cd /home/git/gitlab
```sh
cd /home/git/gitlab
 
sudo -u git -H editor config/gitlab.yml
```
sudo -u git -H editor config/gitlab.yml
```
 
and change the following section:
and change the following section:
 
```yaml
## OmniAuth settings
omniauth:
# Allow login via Twitter, Google, etc. using OmniAuth providers
# Versions prior to 11.4 require this to be set to true
# enabled: true
```yaml
## OmniAuth settings
omniauth:
# Allow login via Twitter, Google, etc. using OmniAuth providers
# Versions prior to 11.4 require this to be set to true
# enabled: true
 
# CAUTION!
# This allows users to login without having a user account first. Define the allowed providers
# using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
allow_single_sign_on: ["saml", "twitter"]
# CAUTION!
# This allows users to login without having a user account first. Define the allowed providers
# using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
allow_single_sign_on: ["saml", "twitter"]
 
auto_link_ldap_user: true
auto_link_ldap_user: true
 
# Locks down those users until they have been cleared by the admin (default: true).
block_auto_created_users: true
```
# Locks down those users until they have been cleared by the admin (default: true).
block_auto_created_users: true
```
 
Now we can choose one or more of the [Supported Providers](#supported-providers)
listed above to continue the configuration process.
@@ -161,14 +161,14 @@ want their accounts to be upgraded to full internal accounts.
**For Omnibus installations**
 
```ruby
gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']
gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']
```
 
**For installations from source**
 
```yaml
omniauth:
external_providers: ['twitter', 'google_oauth2']
omniauth:
external_providers: ['twitter', 'google_oauth2']
```
 
## Using Custom Omniauth Providers
@@ -186,23 +186,31 @@ these cases you can use the Omniauth provider.
These steps are fairly general and you will need to figure out the exact details
from the Omniauth provider's documentation.
 
- Stop GitLab:
- Stop GitLab:
 
sudo service gitlab stop
```sh
sudo service gitlab stop
```
 
- Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile):
- Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile):
 
gem "omniauth-your-auth-provider"
```sh
gem "omniauth-your-auth-provider"
```
 
- Install the new Omniauth provider gem by running the following command:
- Install the new Omniauth provider gem by running the following command:
 
sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
```sh
sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
```
 
> These are the same commands you used during initial installation in the [Install Gems section](../install/installation.md#install-gems) with `--path vendor/bundle --no-deployment` instead of `--deployment`.
> These are the same commands you used during initial installation in the [Install Gems section](../install/installation.md#install-gems) with `--path vendor/bundle --no-deployment` instead of `--deployment`.
 
- Start GitLab:
- Start GitLab:
 
sudo service gitlab start
```sh
sudo service gitlab start
```
 
### Examples
 
@@ -247,8 +255,8 @@ gitlab_rails['omniauth_enabled'] = false
**For installations from source**
 
```yaml
omniauth:
enabled: false
omniauth:
enabled: false
```
 
## Keep OmniAuth user profiles up to date
@@ -258,14 +266,14 @@ You can enable profile syncing from selected OmniAuth providers and for all or f
When authenticating using LDAP, the user's name and email are always synced.
 
```ruby
gitlab_rails['sync_profile_from_provider'] = ['twitter', 'google_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email', 'location']
```
gitlab_rails['sync_profile_from_provider'] = ['twitter', 'google_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email', 'location']
```
 
**For installations from source**
 
```yaml
omniauth:
sync_profile_from_provider: ['twitter', 'google_oauth2']
sync_profile_attributes: ['email', 'location']
omniauth:
sync_profile_from_provider: ['twitter', 'google_oauth2']
sync_profile_attributes: ['email', 'location']
```
doc/integration/salesforce.md
+ 51
− 47
View file @ 33c867b7
@@ -7,73 +7,77 @@ You can integrate your GitLab instance with [Salesforce](https://www.salesforce.
To enable Salesforce OmniAuth provider, you must use Salesforce's credentials for your GitLab instance.
To get the credentials (a pair of Client ID and Client Secret), you must [create a Connected App](https://help.salesforce.com/articleView?id=connected_app_create.htm&type=5) on Salesforce.
 
1. Sign in to [Salesforce](https://login.salesforce.com/).
1. Sign in to [Salesforce](https://login.salesforce.com/).
 
1. In Setup, enter `App Manager` in the Quick Find box, click **App Manager**, then click **New Connected App**.
1. In Setup, enter `App Manager` in the Quick Find box, click **App Manager**, then click **New Connected App**.
 
1. Fill in the application details into the following fields:
- **Connected App Name** and **API Name**: Set to any value but consider something like `<Organization>'s GitLab`, `<Your Name>'s GitLab`, or something else that is descriptive.
- **Contact Email**: Enter the contact email for Salesforce to use when contacting you or your support team.
- **Description**: Description for the application.
1. Fill in the application details into the following fields:
- **Connected App Name** and **API Name**: Set to any value but consider something like `<Organization>'s GitLab`, `<Your Name>'s GitLab`, or something else that is descriptive.
- **Contact Email**: Enter the contact email for Salesforce to use when contacting you or your support team.
- **Description**: Description for the application.
 
![Salesforce App Details](img/salesforce_app_details.png)
1. Select **API (Enable OAuth Settings)** and click on **Enable OAuth Settings**.
1. Fill in the application details into the following fields:
- **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
- **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (openid)** to the right column.
![Salesforce App Details](img/salesforce_app_details.png)
1. Select **API (Enable OAuth Settings)** and click on **Enable OAuth Settings**.
1. Fill in the application details into the following fields:
- **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
- **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (openid)** to the right column.
![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
 
![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
1. Click **Save**.
 
1. On your GitLab server, open the configuration file.
1. On your GitLab server, open the configuration file.
For omnibus package:
```sh
sudo editor /etc/gitlab/gitlab.rb
```
 
For omnibus package:
For installations from source:
 
```sh
sudo editor /etc/gitlab/gitlab.rb
```
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
 
For installations from source:
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
1. Add the provider configuration:
 
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
For omnibus package:
 
1. Add the provider configuration:
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "salesforce",
"app_id" => "SALESFORCE_CLIENT_ID",
"app_secret" => "SALESFORCE_CLIENT_SECRET"
}
]
```
 
For omnibus package:
For installation from source:
 
```ruby
gitlab_rails['omniauth_providers'] = [
{
"name" => "salesforce",
"app_id" => "SALESFORCE_CLIENT_ID",
"app_secret" => "SALESFORCE_CLIENT_SECRET"
}
]
```
```
- { name: 'salesforce',
app_id: 'SALESFORCE_CLIENT_ID',
app_secret: 'SALESFORCE_CLIENT_SECRET'
}
```
 
For installation from source:
1. Change `SALESFORCE_CLIENT_ID` to the Consumer Key from the Salesforce connected application page.
1. Change `SALESFORCE_CLIENT_SECRET` to the Consumer Secret from the Salesforce connected application page.
 
```
- { name: 'salesforce',
app_id: 'SALESFORCE_CLIENT_ID',
app_secret: 'SALESFORCE_CLIENT_SECRET'
}
```
1. Change `SALESFORCE_CLIENT_ID` to the Consumer Key from the Salesforce connected application page.
1. Change `SALESFORCE_CLIENT_SECRET` to the Consumer Secret from the Salesforce connected application page.
![Salesforce App Secret Details](img/salesforce_app_secret_details.png)
![Salesforce App Secret Details](img/salesforce_app_secret_details.png)
 
1. Save the configuration file.
1. [Reconfigure GitLab]( ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure ) or [restart GitLab]( ../administration/restart_gitlab.md#installations-from-source ) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
1. Save the configuration file.
1. [Reconfigure GitLab]( ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure ) or [restart GitLab]( ../administration/restart_gitlab.md#installations-from-source ) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
On the sign in page, there should now be a Salesforce icon below the regular sign in form.
Click the icon to begin the authentication process. Salesforce will ask the user to sign in and authorize the GitLab application.
If everything goes well, the user will be returned to GitLab and will be signed in.
 
NOTE: **Note:**
GitLab requires the email address of each new user. Once the user is logged in using Salesforce, GitLab will redirect the user to the profile page where they will have to provide the email and verify the email.
\ No newline at end of file
GitLab requires the email address of each new user. Once the user is logged in using Salesforce, GitLab will redirect the user to the profile page where they will have to provide the email and verify the email.
doc/integration/shibboleth.md
+ 91
− 91
View file @ 33c867b7
@@ -14,35 +14,35 @@ The following changes are needed to enable Shibboleth:
 
1. Protect omniauth-shibboleth callback URL:
 
```
<Location /users/auth/shibboleth/callback>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
require valid-user
</Location>
Alias /shibboleth-sp /usr/share/shibboleth
<Location /shibboleth-sp>
Satisfy any
</Location>
<Location /Shibboleth.sso>
SetHandler shib
</Location>
```
```
<Location /users/auth/shibboleth/callback>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
require valid-user
</Location>
Alias /shibboleth-sp /usr/share/shibboleth
<Location /shibboleth-sp>
Satisfy any
</Location>
<Location /Shibboleth.sso>
SetHandler shib
</Location>
```
 
1. Exclude shibboleth URLs from rewriting. Add `RewriteCond %{REQUEST_URI} !/Shibboleth.sso` and `RewriteCond %{REQUEST_URI} !/shibboleth-sp`. Config should look like this:
 
```
# Apache equivalent of Nginx try files
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
RewriteCond %{REQUEST_URI} !/shibboleth-sp
RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA]
RequestHeader set X_FORWARDED_PROTO 'https'
```
```
# Apache equivalent of Nginx try files
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
RewriteCond %{REQUEST_URI} !/shibboleth-sp
RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA]
RequestHeader set X_FORWARDED_PROTO 'https'
```
 
1. Edit `/etc/gitlab/gitlab.rb` configuration file to enable OmniAuth and add
Shibboleth as an OmniAuth provider. User attributes will be sent from the
@@ -60,31 +60,31 @@ The following changes are needed to enable Shibboleth:
 
The file should look like this:
 
```
external_url 'https://gitlab.example.com'
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# disable Nginx
nginx['enable'] = false
gitlab_rails['omniauth_allow_single_sign_on'] = true
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [
{
"name" => "'shibboleth"',
"label" => "Text for Login Button",
"args" => {
"shib_session_id_field" => "HTTP_SHIB_SESSION_ID",
"shib_application_id_field" => "HTTP_SHIB_APPLICATION_ID",
"uid_field" => 'HTTP_EPPN',
"name_field" => 'HTTP_CN',
"info_fields" => { "email" => 'HTTP_MAIL'}
}
}
]
```
```
external_url 'https://gitlab.example.com'
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# disable Nginx
nginx['enable'] = false
gitlab_rails['omniauth_allow_single_sign_on'] = true
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_providers'] = [
{
"name" => "'shibboleth"',
"label" => "Text for Login Button",
"args" => {
"shib_session_id_field" => "HTTP_SHIB_SESSION_ID",
"shib_application_id_field" => "HTTP_SHIB_APPLICATION_ID",
"uid_field" => 'HTTP_EPPN',
"name_field" => 'HTTP_CN',
"info_fields" => { "email" => 'HTTP_MAIL'}
}
}
]
```
 
1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../administration/restart_gitlab.md#installations-from-source) GitLab for the changes to take effect if you
installed GitLab via Omnibus or from source respectively.
@@ -97,44 +97,44 @@ The order of the first 2 Location directives is important. If they are reversed,
you will not get a shibboleth session!
 
```
<Location />
Require all granted
ProxyPassReverse http://127.0.0.1:8181
ProxyPassReverse http://YOUR_SERVER_FQDN/
</Location>
<Location /users/auth/shibboleth/callback>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
Require shib-session
</Location>
Alias /shibboleth-sp /usr/share/shibboleth
<Location /shibboleth-sp>
Require all granted
</Location>
<Location /Shibboleth.sso>
SetHandler shib
</Location>
RewriteEngine on
#Don't escape encoded characters in api requests
RewriteCond %{REQUEST_URI} ^/api/v4/.*
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
RewriteCond %{REQUEST_URI} !/shibboleth-sp
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
#Forward all requests to gitlab-workhorse except existing files
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
RewriteCond %{REQUEST_URI} !/shibboleth-sp
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]
RequestHeader set X_FORWARDED_PROTO 'https'
RequestHeader set X-Forwarded-Ssl on
<Location />
Require all granted
ProxyPassReverse http://127.0.0.1:8181
ProxyPassReverse http://YOUR_SERVER_FQDN/
</Location>
<Location /users/auth/shibboleth/callback>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
Require shib-session
</Location>
Alias /shibboleth-sp /usr/share/shibboleth
<Location /shibboleth-sp>
Require all granted
</Location>
<Location /Shibboleth.sso>
SetHandler shib
</Location>
RewriteEngine on
#Don't escape encoded characters in api requests
RewriteCond %{REQUEST_URI} ^/api/v4/.*
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
RewriteCond %{REQUEST_URI} !/shibboleth-sp
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
#Forward all requests to gitlab-workhorse except existing files
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
RewriteCond %{REQUEST_URI} !/shibboleth-sp
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]
RequestHeader set X_FORWARDED_PROTO 'https'
RequestHeader set X-Forwarded-Ssl on
```
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment