Commit f3c4a7c1 authored by Marcel Amirault's avatar Marcel Amirault Committed by Achilleas Pipinellis

Docs: Merge EE doc/user/admin_area to CE

parent 948ffdca
# Geo nodes admin area **[PREMIUM ONLY]**
For more information about setting up GitLab Geo, read the
[Geo documentation](https://docs.gitlab.com/ee/administration/geo/replication/index.html).
When you're done, you can navigate to **Admin area > Geo** (`/admin/geo/nodes`).
## Common settings
All Geo nodes have the following settings:
| Setting | Description |
| --------| ----------- |
| Primary | This marks a Geo Node as primary. There can be only one primary, make sure that you first add the primary node and then all the others. |
| URL | The instance's full URL, in the same way it is configured in `/etc/gitlab/gitlab.rb` (Omnibus GitLab installations) or `gitlab.yml` (source based installations). |
The node you're reading from is indicated with a green `Current node` label, and
the primary is given a blue `Primary` label. Remember that you can only make
changes on the primary!
## Secondary node settings
Secondaries have a number of additional settings available:
| Setting | Description |
|---------------------------|-------------|
Selective synchronization | Enable Geo [selective sync](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) for this **secondary** node. |
| Repository sync capacity | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling repositories. |
| File sync capacity | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling files. |
## Geo backfill
Secondaries are notified of changes to repositories and files by the primary,
and will always attempt to synchronize those changes as quickly as possible.
Backfill is the act of populating the secondary with repositories and files that
existed *before* the secondary was added to the database. Since there may be
extremely large numbers of repositories and files, it's infeasible to attempt to
download them all at once, so GitLab places an upper limit on the concurrency of
these operations.
How long the backfill takes is a function of the maximum concurrency, but higher
values place more strain on the primary node. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3107),
the limits are configurable - if your primary node has lots of surplus capacity,
you can increase the values to complete backfill in a shorter time. If it's
under heavy load and backfill is reducing its availability for normal requests,
you can decrease them.
## Using a different URL for synchronization
The **primary** node's Internal URL is used by **secondary** nodes to contact it
(to sync repositories, for example). The name Internal URL distinguishes it from
[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab)
which is used by users. Internal URL does not need to be a private address.
Internal URL defaults to External URL, but you can customize it under
**Admin area > Geo Nodes**.
......@@ -15,13 +15,16 @@ Only admin users can access the Admin Area.
The Admin Area is made up of the following sections:
| Section | Description |
|:------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------|
|:---------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------|
| Overview | View your GitLab [Dashboard](#admin-dashboard), and administer [projects](#administer-projects), users, groups, jobs, runners, and Gitaly servers. |
| Monitoring | View GitLab system information, and information on background jobs, logs, [health checks](monitoring/health_check.md), request profiles, and audit logs. |
| Messages | Send and manage [broadcast messages](broadcast_messages.md) for your users. |
| System Hooks | Configure [system hooks](../../system_hooks/system_hooks.md) for many events. |
| Applications | Create system [OAuth applications](../../integration/oauth_provider.md) for integrations with other services. |
| Abuse Reports | Manage [abuse reports](abuse_reports.md) submitted by your users. |
| License **[STARTER ONLY]** | Upload, display, and remove [licenses](license.md). |
| Push Rules **[STARTER]** | Configure pre-defined git [push rules](https://docs.gitlab.com/ee/push_rules/push_rules.html) for projects. |
| Geo **[PREMIUM ONLY]** | Configure and maintain [Geo nodes](geo_nodes.md). |
| Deploy Keys | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys). |
| Service Templates | Create [service templates](../project/integrations/services_templates.md) for projects. |
| Labels | Create and maintain [labels](labels.md) for your GitLab instance. |
......
# Activate all GitLab Enterprise Edition functionality with a license **[STARTER ONLY]**
To activate all GitLab Enterprise Edition (EE) functionality, you need to upload
a license. Once you've received your license from GitLab Inc., you can upload it
by **signing into your GitLab instance as an admin**.
The license has the form of a base64 encoded ASCII text with a `.gitlab-license`
extension and can be obtained when you [purchase one][pricing] or when you sign
up for a [free trial].
NOTE: **Note:**
As of GitLab Enterprise Edition 9.4.0, a newly-installed instance without an
uploaded license will only have the Core features active. A trial license will
activate all Ultimate features, but after
[the trial expires](#what-happens-when-your-license-expires), some functionality
will be locked.
## Uploading your license
The very first time you visit your GitLab EE installation signed in as an admin,
you should see a note urging you to upload a license with a link that takes you
straight to the License admin area.
Otherwise, you can:
1. Navigate manually to the **Admin Area** by clicking the wrench icon in the menu bar.
![Admin area icon](img/admin_wrench.png)
1. And then going to the **License** tab and click on **Upload New License**.
![License admin area](img/license_admin_area.png)
1. If you've received a `.gitlab-license` file, you should have already downloaded
it in your local machine. You can then upload it directly by choosing the
license file and clicking the **Upload license** button. In the image below,
you can see that the selected license file is named `GitLab.gitlab-license`.
![Upload license](img/license_upload.png)
If you've received your license as plain text, you need to select the
"Enter license key" option, copy the license, paste it into the "License key"
field and click **Upload license**.
---
Once the license is uploaded, all GitLab Enterprise Edition functionality
will be active until the end of the license period. When that period ends, the
instance will [fall back](#what-happens-when-your-license-expires) to Core-only
functionality.
You can review the license details at any time in the License section of the
Admin Area.
![License details](img/license_details.png)
## Notification before the license expires
One month before the license expires, a message informing when the expiration
is due to, will start appearing to GitLab admins. Make sure that you update your
license, otherwise you will miss all the paid features if it expires.
## What happens when your license expires
In case your license expires, GitLab will lock down some features like Git pushes,
issue creation, etc., and a message to inform of the expired license will be
presented to all admins.
In order to get back all the previous functionality, a new license must be uploaded.
To fall back to having only the Core features active, you'll need to delete the
expired license(s).
## License history
It's possible to upload and view more than one license,
but only the latest license will be used as the active license.
[free trial]: https://about.gitlab.com/free-trial/
[pricing]: https://about.gitlab.com/pricing/
# Account and limit settings
## Repository size limit **[STARTER]**
> [Introduced][ee-740] in [GitLab Enterprise Edition 8.12][ee-8.12].
Repositories within your GitLab instance can grow quickly, especially if you are
using LFS. Their size can grow exponentially and eat up your storage device quite
fast.
In order to avoid this from happening, you can set a hard limit for your
repositories' size. This limit can be set globally, per group, or per project,
with per project limits taking the highest priority.
There are numerous cases where you'll need to set up a limit for repository size.
For instance, consider the following workflow:
1. Your team develops apps which demand large files to be stored in
the application repository.
1. Although you have enabled [Git LFS](../../../workflow/lfs/manage_large_binaries_with_git_lfs.html#git-lfs)
to your project, your storage has grown significantly.
1. Before you blow your storage limit up, you set up a limit of 10 GB
per repository.
### How it works
Only a GitLab administrator can set those limits. Setting the limit to `0` means
there are no restrictions.
These settings can be found within:
- Each project's settings.
- A group's settings.
- The **Size limit per repository (MB)** field in the **Account and limit** section of a GitLab instance's
settings by navigating to either:
- **Admin Area > Settings > General**.
- The path `/admin/application_settings`.
The very first push of a new project cannot be checked for size as of now, so
the first push will allow you to upload more than the limit dictates, but every
subsequent push will be denied. LFS objects, however, can be checked on first
push and **will** be rejected if the sum of their sizes exceeds the maximum
allowed repository size.
For more manually purging the files, read the docs on
[reducing the repository size using Git][repo-size].
> **Note:**
> For GitLab.com, the repository size limit is 10 GB.
[ee-740]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/740
[repo-size]: ../../project/repository/reducing_the_repo_size_using_git.md
[ee-8.12]: https://about.gitlab.com/2016/09/22/gitlab-8-12-released/#limit-project-size-ee
......@@ -10,8 +10,8 @@ You can find it in the admin area, under **Settings > Continuous Integration and
To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md)
for all projects:
1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
1. Check (or uncheck to disable) the box that says "Default to Auto DevOps pipeline for all projects".
1. Go to **Admin area > Settings > Continuous Integration and Deployment**
1. Check (or uncheck to disable) the box that says "Default to Auto DevOps pipeline for all projects"
1. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/index.md#auto-devops-base-domain)
which is going to be used for Auto Deploy and Auto Review Apps.
1. Hit **Save changes** for the changes to take effect.
......@@ -24,9 +24,9 @@ If you want to disable it for a specific project, you can do so in
## Maximum artifacts size **[CORE ONLY]**
The maximum size of the [job artifacts][art-yml] can be set in the Admin area
of your GitLab instance. The value is in *MB* and the default is 100MB per job;
on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
The maximum size of the [job artifacts](../../../administration/job_artifacts.md)
can be set in the Admin area of your GitLab instance. The value is in *MB* and
the default is 100MB per job; on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
To change it:
......@@ -50,6 +50,79 @@ This setting is set per job and can be overridden in
[`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifactsexpire_in).
To disable the expiration, set it to `0`. The default unit is in seconds.
## Shared Runners pipeline minutes quota **[STARTER ONLY]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1078)
in GitLab Starter 8.16.
If you have enabled shared Runners for your GitLab instance, you can limit their
usage by setting a maximum number of pipeline minutes that a group can use on
shared Runners per month. Setting this to `0` (default value) will grant
unlimited pipeline minutes. While build limits are stored as minutes, the
counting is done in seconds. Usage resets on the first day of each month.
On GitLab.com, the quota is calculated based on your
[subscription plan](https://about.gitlab.com/pricing/#gitlab-com).
To change the pipelines minutes quota:
1. Go to **Admin area > Settings > Continuous Integration and Deployment**
1. Set the pipeline minutes quota limit.
1. Hit **Save changes** for the changes to take effect
---
While the setting in the Admin area has a global effect, as an admin you can
also change each group's pipeline minutes quota to override the global value.
1. Navigate to the **Groups** admin area and hit the **Edit** button for the
group you wish to change the pipeline minutes quota.
1. Set the pipeline minutes quota to the desired value
1. Hit **Save changes** for the changes to take effect.
Once saved, you can see the build quota in the group admin view.
The quota can also be viewed in the project admin view if shared Runners
are enabled.
![Project admin info](img/admin_project_quota_view.png)
When the pipeline minutes quota for a group is set to a value different than 0,
the **Pipelines quota** page is available to the group page settings list.
You can see there an overview of the pipeline minutes quota of all projects of
the group.
![Group pipelines quota](img/group_pipelines_quota.png)
## Extra Shared Runners pipeline minutes quota
NOTE: **Note:**
Only available on GitLab.com.
If you have a Group with a [paid plan](https://about.gitlab.com/pricing/#gitlab-com) on GitLab.com,
then you can purchase additional CI minutes so your pipelines will not be blocked after you have
used all your CI minutes from your main quota.
In order to purchase additional minutes, you should follow these steps:
1. Go to **Group > Settings > Pipelines quota**. Once you are on that page, click on **Buy additional minutes**.
![Buy additional minutes](img/buy_btn.png)
1. Locate the subscription card that is linked to your group on GitLab.com,
click on **Buy more CI minutes**, and complete the details about the transaction.
![Buy additional minutes](img/buy_minutes_card.png)
1. Once we have processed your payment, the extra CI minutes
will be synced to your Group and you can visualize it from the
**Group > Settings > Pipelines quota** page:
![Additional minutes](img/additional_minutes.png)
NOTE: **Important note**: If you have some minutes used over your default quota, these minutes will
be deducted from your Additional Minutes quota immediately after your purchase of additional
minutes.
## Archive jobs **[CORE ONLY]**
Archiving jobs is useful for reducing the CI/CD footprint on the system by
......
......@@ -4,6 +4,22 @@
The logo in the header of some emails can be customized, see the [logo customization section](../../../customization/branded_page_and_email_header.md).
## Custom additional text **[PREMIUM ONLY]**
>[Introduced][ee-5031] in [GitLab Premium][eep] 10.7.
The additional text will appear at the bottom of any email and can be used for
legal/auditing/compliance reasons.
1. Go to **Admin area > Settings** (`/admin/application_settings`).
1. Under the **Email** section, change the **Additional text** field.
1. Hit **Save** for the changes to take effect.
![Admin email settings](img/email_settings.png)
[ee-5031]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5031
[eep]: https://about.gitlab.com/pricing/
## Custom hostname for private commit emails
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22560) in GitLab 11.5.
......
# External authorization control
# External authorization control **[CORE ONLY]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4216) in
> [GitLab Premium](https://about.gitlab.com/pricing) 10.6.
......
......@@ -6,6 +6,7 @@ instance like sign-up restrictions, account limits and quota, metrics, etc.
Navigate to it by going to **Admin area > Settings**. Some of the settings
include:
- [Account and limit settings](account_and_limit_settings.md) **[STARTER]**
- [Continuous Integration and Deployment](continuous_integration.md)
- [Email](email.md)
- [Sign up restrictions](sign_up_restrictions.md)
......@@ -13,6 +14,7 @@ include:
- [Third party offers](third_party_offers.md)
- [Usage statistics](usage_statistics.md)
- [Visibility and access controls](visibility_and_access_controls.md)
- [Custom templates repository](instance_template_repository.md) **[PREMIUM]**
NOTE: **Note:**
You can change the [first day of the week](../../profile/preferences.md) for the entire GitLab instance
......
# Instance template repository **[PREMIUM ONLY]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5986) in
> [GitLab Premium](https://about.gitlab.com/pricing) 11.3.
## Overview
In hosted systems, enterprises often have a need to share their own templates
across teams. This feature allows an administrator to pick a project to be the
instance-wide collection of file templates. These templates are then exposed to
all users [via the web editor](../../project/repository/web_editor.md#template-dropdowns)
while the project remains secure.
## Configuration
As an administrator, navigate to **Admin area > Settings > Templates** and
select the project to serve as the custom template repository.
![File templates in the admin area](img/file_template_admin_area.png)
Once a project has been selected, you can add custom templates to the repository,
and they will appear in the appropriate places in the
[frontend](../../project/repository/web_editor.md#template-dropdowns) and
[API](../../../api/settings.md).
Templates must be added to a specific subdirectory in the repository,
corresponding to the kind of template. The following types of custom templates
are supported:
| Type | Directory | Extension |
| :---------------: | :-----------: | :-----------: |
| `Dockerfile` | `Dockerfile` | `.dockerfile` |
| `.gitignore` | `gitignore` | `.gitignore` |
| `.gitlab-ci.yml` | `gitlab-ci` | `.yml` |
| `LICENSE` | `LICENSE` | `.txt` |
Each template must go in its respective subdirectory, have the correct
extension and not be empty. So, the hierarchy should look like this:
```text
|-- README.md
|-- Dockerfile
|-- custom_dockerfile.dockerfile
|-- another_dockerfile.dockerfile
|-- gitignore
|-- custom_gitignore.gitignore
|-- another_gitignore.gitignore
|-- gitlab-ci
|-- custom_gitlab-ci.yml
|-- another_gitlab-ci.yml
|-- LICENSE
|-- custom_license.txt
|-- another_license.txt
```
Once this is established, the list of custom templates will be included when
creating a new file and the template type is selected. These will appear at the
top of the list.
![Custom template dropdown menu](img/file_template_user_dropdown.png)
If this feature is disabled or no templates are present, there will be
no "Custom" section in the selection dropdown.
......@@ -49,5 +49,15 @@ block access to the server itself. The ports used for the protocol, be it SSH or
HTTP, will still be accessible. What GitLab does is restrict access on the
application level.
## Allow mirrors to be set up for projects
> [Introduced][ee-3586] in GitLab 10.3.
This option is enabled by default. By disabling it, both pull and push mirroring will no longer
work in every repository and can only be re-enabled on a per-project basis by an admin.
![Mirror settings](img/mirror_settings.png)
[ce-4696]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4696
[ce-18021]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18021
[ee-3586]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3586
Markdown is supported
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