Docs: (EE Port) Fix all anchors in Admin docs

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -14,7 +14,7 @@ Managing a large number of users in GitLab can become a burden for system admini
 In this guide we will focus on configuring GitLab with Active Directory. [Active Directory](https://en.wikipedia.org/wiki/Active_Directory) is a popular LDAP compatible directory service provided by Microsoft, included in all modern Windows Server operating systems.
-GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/2012/02/22/gitlab-version-2-2/). With GitLab LDAP [group syncing](#group-syncing-ee) being added to GitLab Enterprise Edition in [version 6.0](https://about.gitlab.com/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab.
+GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/2012/02/22/gitlab-version-2-2/). With GitLab LDAP [group syncing](../how_to_configure_ldap_gitlab_ee/index.html#group-sync) being added to GitLab Enterprise Edition in [version 6.0](https://about.gitlab.com/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab.
 ## Getting started
@@ -111,7 +111,7 @@ The initial configuration of LDAP in GitLab requires changes to the `gitlab.rb`
 The two Active Directory specific values are `active_directory: true` and `uid: 'sAMAccountName'`. `sAMAccountName` is an attribute returned by Active Directory used for GitLab usernames. See the example output from `ldapsearch` for a full list of attributes a "person" object (user) has in **AD** - [`ldapsearch` example](#using-ldapsearch-unix)
-> Both group_base and admin_group configuration options are only available in GitLab Enterprise Edition. See [GitLab EE - LDAP Features](#gitlab-enterprise-edition---ldap-features)
+> Both group_base and admin_group configuration options are only available in GitLab Enterprise Edition. See [GitLab EE - LDAP Features](../how_to_configure_ldap_gitlab_ee/index.html#gitlab-enterprise-edition---ldap-features)
 ### Example `gitlab.rb` LDAP

doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md

@@ -16,7 +16,7 @@ The present article follows [How to Configure LDAP with GitLab CE](../how_to_con
 [GitLab Enterprise Edition (EE)](https://about.gitlab.com/pricing/) has a number of advantages when it comes to integrating with Active Directory (LDAP):
-- [Administrator Sync](#administrator-sync): As an extension of group sync, you can automatically manage your global GitLab administrators. Specify a group CN for `admin_group` and all members of the LDAP group will be given administrator privileges.
+- [Administrator Sync](../ldap-ee.md#administrator-sync): As an extension of group sync, you can automatically manage your global GitLab administrators. Specify a group CN for `admin_group` and all members of the LDAP group will be given administrator privileges.
 - [Group Sync](#group-sync): This allows GitLab group membership to be automatically updated based on LDAP group members.
 - [Multiple LDAP servers](#multiple-ldap-servers): The ability to configure multiple LDAP servers. This is useful if an organization has different LDAP servers within departments. This is not designed for failover. We're working on [supporting LDAP failover](https://gitlab.com/gitlab-org/gitlab-ee/issues/139) in GitLab.

doc/administration/auth/ldap.md

@@ -39,7 +39,7 @@ immediately block all access.
 NOTE: **Note**:
 GitLab Enterprise Edition Starter supports a
-[configurable sync time](ldap-ee.md#adjusting-ldap-user-and-group-sync-schedules),
+[configurable sync time](ldap-ee.md#adjusting-ldap-user-sync-schedule),
 with a default of one hour.
 ## Git password authentication
@@ -338,7 +338,7 @@ group, you can use the following syntax:
 Find more information about this "LDAP_MATCHING_RULE_IN_CHAIN" filter at
 <https://docs.microsoft.com/en-us/windows/desktop/ADSI/search-filter-syntax>. Support for
 nested members in the user filter should not be confused with
-[group sync nested groups support (EE only)](ldap-ee.md#supported-ldap-group-types-attributes).
+[group sync nested groups support (EE only)](ldap-ee.md#supported-ldap-group-typesattributes).
 Please note that GitLab does not support the custom filter syntax used by
 omniauth-ldap.

doc/administration/auth/okta.md

 # Okta SSO provider
-Okta is a [Single Sign-on provider][okta-sso] that can be used to authenticate
+Okta is a [Single Sign-on provider](https://www.okta.com/products/single-sign-on/) that can be used to authenticate
 with GitLab.
 The following documentation enables Okta as a SAML provider.
@@ -140,7 +140,7 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
       }
     ```
-1. [Reconfigure][reconf] or [restart] GitLab for Omnibus and installations
+1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../restart_gitlab.md#installations-from-source) GitLab for Omnibus and installations
    from source respectively for the changes to take effect.
 You might want to try this out on an incognito browser window.
@@ -150,10 +150,5 @@ You might want to try this out on an incognito browser window.
 >**Note:**
 Make sure the groups exist and are assigned to the Okta app.
-You can take a look of the [SAML documentation][saml] on external groups since
+You can take a look of the [SAML documentation](../../integration/saml.md#marking-users-as-external-based-on-saml-groups) on external groups since
 it works the same.
-
-[okta-sso]: https://www.okta.com/products/single-sign-on/
-[saml]: ../../integration/saml.md#external-groups
-[reconf]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart]: ../restart_gitlab.md#installations-from-source

doc/administration/compliance.md

@@ -6,13 +6,13 @@ GitLab’s [security features](../security/README.md) may also help you meet rel
 |Feature   |GitLab tier |GitLab.com |
 | ---------| :--------: | :-------: |
-|**[Restrict SSH Keys](../README.html#administrator-documentation)**<br>Control the technology and key length of SSH keys used to access GitLab|Core+||
-|**[Granular user roles and flexible permissions](../user/permissions.html)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Core+|✓|
-|**[Enforce TOS acceptance](../user/admin_area/settings/terms.html)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic.|Core+||
-|**[Email all users of a project, group, or entire server](../user/admin_area/settings/terms.html)**<br>An admin can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Starter+||
+|**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab|Core+||
+|**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Core+|✓|
+|**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic.|Core+||
+|**[Email all users of a project, group, or entire server](../user/admin_area/settings/terms.md)**<br>An admin can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Starter+||
 |**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system.|Starter+||
-|**[Lock project membership to group](../workflow/groups.html#lock-project-membership-to-members-of-this-group)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓|
-|**[LDAP group sync](../administration/auth/ldap-ee.html#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+||
-|**[LDAP group sync filters](../administration/auth/ldap-ee.html#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||
-|**[Audit logs](../administration/audit_events.html)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze and track every change.|Premium+||
-|**[Auditor users](../administration/auditor_users.html)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||
+|**[Lock project membership to group](../user/group/index.md#member-lock-starter)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓|
+|**[LDAP group sync](auth/ldap-ee.md#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+||
+|**[LDAP group sync filters](auth/ldap-ee.md#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||
+|**[Audit logs](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze and track every change.|Premium+||
+|**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -31,7 +31,7 @@ To bring the former **primary** node up to date:
     > the GitLab instance from scratch and set it up as a **secondary** node by
     > following [Setup instructions][setup-geo]. In this case, you don't need to follow the next step.
     >
-    > **Note 2:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domains-dns-record)
+    > **Note 2:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
     > for this node during disaster recovery procedure you may need to [block
     > all the writes to this node](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/gitlab-geo/planned-failover.md#block-primary-traffic)
     > during this procedure.

doc/administration/geo/disaster_recovery/index.md

@@ -224,7 +224,7 @@ sudo rm -rf /var/opt/gitlab/geo-postgresql
 ## Promoting secondary Geo replica in multi-secondary configurations
 If you have more than one **secondary** node and you need to promote one of them, we suggest you follow
-[Promoting **secondary** Geo node in single-secondary configurations](#promoting-secondary-geo-node-in-single-secondary-configurations)
+[Promoting a **secondary** Geo node in single-secondary configurations](#promoting-a-secondary-geo-node-in-single-secondary-configurations)
 and after that you also need two extra steps.
 ### Step 1. Prepare the new **primary** node to serve one or more **secondary** nodes

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -113,7 +113,7 @@ If any objects are failing to replicate, this should be investigated before
 scheduling the maintenance window. Following a planned failover, anything that
 failed to replicate will be **lost**.
-You can use the [Geo status API][geo-status-api] to review failed objects and
+You can use the [Geo status API](../../../api/geo_nodes.md#retrieve-project-sync-or-verification-failures-that-occurred-on-the-current-node) to review failed objects and
 the reasons for failure.
 A common cause of replication failures is the data being missing on the
@@ -223,7 +223,6 @@ Don't forget to remove the broadcast message after failover is complete.
 [ee-5064]: https://gitlab.com/gitlab-org/gitlab-ee/issues/5064
 [foreground-verification]: ../../raketasks/check.md
 [background-verification]: background_verification.md
-[geo-status-api]: ../../../api/geo_nodes.html#retrieve-project-sync-failures-ocurred-on-the-current-node
 [limitations]: ../replication/index.md#current-limitations
 [moving-repositories]: ../../operations/moving_repositories.md
 [os-conf]: ../replication/object_storage.md#configuration

doc/administration/geo/replication/configuration_source.md

@@ -11,7 +11,7 @@ using the Omnibus GitLab packages, follow the
 NOTE: **Note:**
 This is the final step in setting up a **secondary** node. Stages of the setup
 process must be completed in the documented order. Before attempting the steps
-in this stage, [complete all prior stages][setup-geo-source].
+in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source-deprecated).
 The basic steps of configuring a **secondary** node are to:
@@ -88,7 +88,7 @@ the **secondary** node with the same credentials as used for the **primary** nod
 ### Step 2. Manually replicate the **primary** node's SSH host keys
-Read [Manually replicate the **primary** node's SSH host keys][configuration-replicate-ssh]
+Read [Manually replicate the **primary** node's SSH host keys](configuration.md#step-2-manually-replicate-the-primary-nodes-ssh-host-keys)
 ### Step 3. Add the **secondary** GitLab node
@@ -166,10 +166,8 @@ Read [Selective synchronization][configuration-selective-replication].
 Read the [troubleshooting document][troubleshooting].
-[setup-geo-source]: index.md#using-gitlab-installed-from-source
 [gitlab-org/gitlab-ee#3789]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3789
 [configuration]: configuration.md
-[configuration-replicate-ssh]: configuration.md#step-2-manually-replicate-primary-ssh-host-keys
 [configuration-selective-replication]: configuration.md#selective-synchronization
 [configuration-verify-node]: configuration.md#step-7-verify-proper-functioning-of-the-secondary-node
 [troubleshooting]: troubleshooting.md

doc/administration/geo/replication/database_source.md

@@ -8,7 +8,7 @@ using the Omnibus GitLab packages, follow the
 NOTE: **Note:**
 The stages of the setup process must be completed in the documented order.
-Before attempting the steps in this stage, [complete all prior stages][toc].
+Before attempting the steps in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source-deprecated).
 This document describes the minimal steps you have to take in order to
 replicate your **primary** GitLab database to a **secondary** node's database. You may
@@ -423,7 +423,6 @@ Read the [troubleshooting document](troubleshooting.md).
 [pgback]: http://www.postgresql.org/docs/9.6/static/app-pgbasebackup.html
 [replication user]:https://wiki.postgresql.org/wiki/Streaming_Replication
 [FDW]: https://www.postgresql.org/docs/9.6/static/postgres-fdw.html
-[toc]: index.md#using-gitlab-installed-from-source
 [database]: database.md
 [add-geo-node]: configuration.md#step-3-add-the-secondary-gitlab-node
 [database-replication]: database.md#step-2-configure-the-secondary-server

doc/administration/geo/replication/object_storage.md

@@ -13,12 +13,12 @@ they can use a replicated storage bucket. At this time GitLab does not
 take care of content replication in object storage.
 For LFS, follow the documentation to
-[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
+[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
 For CI job artifacts, there is similar documentation to configure
 [jobs artifact object storage](../../job_artifacts.md#using-object-storage)
-For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage)
+For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage-core-only)
 You should enable and configure object storage on both **primary** and **secondary**
 nodes. Migrating existing data to object storage should be performed on the

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -112,11 +112,11 @@ sudo gitlab-ctl reconfigure
 ```
 If you do not perform this step, you may find that two-factor authentication
-[is broken following DR](faq.md#i-followed-the-disaster-recovery-instructions-and-now-two-factor-auth-is-broken).
+[is broken following DR](../disaster_recovery/index.html#i-followed-the-disaster-recovery-instructions-and-now-two-factor-auth-is-broken).
 To prevent SSH requests to the newly promoted **primary** node from failing
 due to SSH host key mismatch when updating the **primary** node domain's DNS record
-you should perform the step to [Manually replicate **primary** SSH host keys][configuration-replicate-ssh] in each
+you should perform the step to [Manually replicate **primary** SSH host keys](configuration.md#step-2-manually-replicate-the-primary-nodes-ssh-host-keys) in each
 **secondary** node.
 ## Upgrading to GitLab 10.4
@@ -131,7 +131,7 @@ In GitLab 10.2, synchronizing secondaries over SSH was deprecated. In 10.3,
 support is removed entirely. All installations will switch to the HTTP/HTTPS
 cloning method instead. Before upgrading, ensure that all your Geo nodes are
 configured to use this method and that it works for your installation. In
-particular, ensure that [Git access over HTTP/HTTPS is enabled][configuration-git-over-http].
+particular, ensure that [Git access over HTTP/HTTPS is enabled](configuration.md#step-6-enable-git-access-over-httphttps).
 Synchronizing repositories over the public Internet using HTTP is insecure, so
 you should ensure that you have HTTPS configured before upgrading. Note that
@@ -402,5 +402,3 @@ and it is required since 10.0.
 [Hashed Storage]: ../../repository_storage_types.md
 [hashed-migration]: ../../raketasks/storage.md
 [ssh-fast-lookup]: ../../operations/fast_ssh_key_lookup.md
-[configuration-replicate-ssh]: configuration.md#step-2-manually-replicate-primary-ssh-host-keys
-[configuration-git-over-http]: configuration.md#step-6-enable-git-access-over-http-https

doc/administration/index.md

@@ -152,7 +152,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
 - [Job traces](job_traces.md): Information about the job traces (logs).
 - [Register Shared and specific Runners](../ci/runners/README.md#registering-a-shared-runner): Learn how to register and configure Shared and specific Runners to your own instance.
-- [Shared Runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for Shared Runners.
+- [Shared Runners pipelines quota](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#shared-runners-pipeline-minutes-quota-starter-only): Limit the usage of pipeline minutes for Shared Runners. **[STARTER ONLY]**
 - [Enable/disable Auto DevOps](../topics/autodevops/index.md#enablingdisabling-auto-devops): Enable or disable Auto DevOps for your instance.
 ## Git configuration options

doc/administration/job_artifacts.md

@@ -274,7 +274,7 @@ you can flip the feature flag from a Rails console.
 ## Set the maximum file size of the artifacts
 Provided the artifacts are enabled, you can change the maximum file size of the
-artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
+artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
 ## Storage statistics

doc/administration/monitoring/prometheus/index.md

@@ -17,7 +17,7 @@ access to high quality time-series monitoring of GitLab services.
 ## Overview
 Prometheus works by periodically connecting to data sources and collecting their
-performance metrics via the [various exporters](#prometheus-exporters). To view
+performance metrics via the [various exporters](#bundled-software-metrics). To view
 and work with the monitoring data, you can either
 [connect directly to Prometheus](#viewing-performance-metrics) or utilize a
 dashboard tool like [Grafana].

doc/administration/operations/fast_ssh_key_lookup.md

@@ -37,7 +37,7 @@ public SSH keys for users allowed to access GitLab. However, to maintain a
 single source of truth, [Geo](../../gitlab-geo/README.md) needs to be configured to perform SSH fingerprint
 lookups via database lookup.
-As part of [setting up Geo](../../gitlab-geo/README.md#setup-instructions),
+As part of [setting up Geo](../geo/replication/index.md#setup-instructions),
 you will be required to follow the steps outlined below for both the primary and
 secondary nodes, but note that the `Write to "authorized keys" file` checkbox
 only needs to be unchecked on the primary node since it will be reflected

doc/administration/raketasks/uploads/migrate.md

@@ -2,7 +2,7 @@
 ## Migrate to Object Storage
-After [configuring the object storage](../../uploads.md#using-object-storage) for GitLab's uploads, you may use this task to migrate existing uploads from the local storage to the remote storage.
+After [configuring the object storage](../../uploads.md#using-object-storage-core-only) for GitLab's uploads, you may use this task to migrate existing uploads from the local storage to the remote storage.
 >**Note:**
 All of the processing will be done in a background worker and requires **no downtime**.

doc/administration/repository_checks.md

@@ -31,7 +31,7 @@ panel.
 If the repository check fails for some repository you should look up the error
 in `repocheck.log`:
-- in the [admin panel](logs.md#repocheck-log)
+- in the [admin panel](logs.md#repochecklog)
 - or on disk, see:
     - `/var/log/gitlab/gitlab-rails` for Omnibus installations
     - `/home/git/gitlab/log` for installations from source

doc/gitlab-geo/README.md

+---
+redirect_to: '../administration/geo/replication/index.md'
+---
+
 This document was moved to [another location](../administration/geo/replication/index.md).

doc/gitlab-geo/configuration.md

+---
+redirect_to: '../administration/geo/replication/configuration.md'
+---
+
 This document was moved to [another location](../administration/geo/replication/configuration.md).