fixing links

admin_guide/aggregate_logging.adoc

@@ -25,6 +25,8 @@ These solutions are a work in progress. As packaging improvements are made these
 instructions will be simplified.
 ====
 
+[[using-a-centralized-file-system]]
+
 == Using a Centralized File System
 
 This option reads all container logs and forwards them to a central server for
@@ -147,6 +149,8 @@ contents:
 Any errors are logged in the *_/var/log/td-agent/td-agent.log_* file.
 ====
 
+[[optional-method-to-verify-working-nodes]]
+
 === Optional Method to Verify Working Nodes
 
 You can optionally set up the master to be the aggregator to test and verify
@@ -211,6 +215,8 @@ Any errors are logged in the *_/var/log/td-agent/td-agent.log_* file.
 You should now find all the containers' logs available on the master in the
 *_/var/log/td-agent/containers.log_* file.
 
+[[using-elasticsearch]]
+
 == Using Elasticsearch
 
 https://www.elastic.co/products/elasticsearch[*Elasticsearch*] is an open source
@@ -229,6 +235,8 @@ Enabling aggregated logging to *Elasticsearch* involves:
 . link:#creating-logging-pods[Creating logging pods]
 . link:#creating-the-kibana-service[Creating the *Kibana* service]
 
+[[creating-an-elasticsearch-cluster]]
+
 === Creating an Elasticsearch cluster
 
 Logs are stored in an *Elasticsearch* cluster running on OpenShift. This cluster
@@ -336,6 +344,8 @@ $ oc scale --replicas=3 rc elasticsearch
 ----
 ====
 
+[[creating-logging-pods]]
+
 === Creating Logging Pods
 
 To read the container logs, a static pod must be deployed on each node. To do
@@ -418,6 +428,8 @@ yellow open   logstash-2015.06.05   5   1        540            0      251kb
 If the value for `docs.count` is more than 0, then log records are being
 correctly sent to *Elasticsearch*.
 
+[[creating-the-kibana-search]]
+
 === Creating the Kibana Service
 
 To create the *Kibana* service, save the following specification to your file

admin_guide/configuring_authentication.adoc

@@ -31,6 +31,8 @@ link:#token-options[token], link:#grant-options[grant], or
 link:#session-options[session options], you must run the master from a
 configuration file.
 
+[[identity-providers]]
+
 == Identity Providers
 You can configure the master for authentication using your desired identity
 provider by modifying the link:master_node_configuration.html[master
@@ -46,16 +48,18 @@ There are three parameters common to all identity providers:
 the CLI) are sent a `WWW-Authenticate` challenge header. Not supported by all
 identity providers.
 
-NOTE: To prevent CSRF attacks against browser clients, Basic authentication challenges 
-are only sent if a `X-CSRF-Token` header is present on the request. Clients that expect 
+NOTE: To prevent CSRF attacks against browser clients, Basic authentication challenges
+are only sent if a `X-CSRF-Token` header is present on the request. Clients that expect
 to receive Basic `WWW-Authenticate` challenges should set this header to a non-empty value.
 
 .^|`login`     | When `true`, unauthenticated token requests from web clients (like the web
 console) are redirected to a login page backed by this provider. Not supported
 by all identity providers.
 |===
 
-=== Allow All [[AllowAllPasswordIdentityProvider]]
+[[AllowAllPasswordIdentityProvider]]
+
+=== Allow All
 Set `*AllowAllPasswordIdentityProvider*` in the `*identityProviders*` stanza to
 allow any non-empty user name and password to log in. This is the default
 identity provider when running OpenShift without a
@@ -82,7 +86,9 @@ the CLI) are sent a `WWW-Authenticate` challenge header for this provider.
 console) are redirected to a login page backed by this provider.
 ====
 
-=== Deny All [[DenyAllPasswordIdentityProvider]]
+[[DenyAllPasswordIdentityProvider]]
+
+=== Deny All
 Set `*DenyAllPasswordIdentityProvider*` in the `*identityProviders*` stanza to deny
 access for all user name and passwords.
 
@@ -107,7 +113,9 @@ CLI) are sent a `WWW-Authenticate` challenge header for this provider.
 console) are redirected to a login page backed by this provider.
 ====
 
-=== HTPasswd [[HTPasswdPasswordIdentityProvider]]
+[[HTPasswdPasswordIdentityProvider]]
+
+=== HTPasswd
 
 Set `*HTPasswdPasswordIdentityProvider*` in the `*identityProviders*` stanza to
 validate user names and passwords against a flat file generated using
@@ -162,7 +170,9 @@ console) are redirected to a login page backed by this provider.
 http://httpd.apache.org/docs/2.4/programs/htpasswd.html[`htpasswd`].
 ====
 
-=== Basic Authentication (Remote) [[BasicAuthPasswordIdentityProvider]]
+[[BasicAuthPasswordIdentityProvider]]
+
+=== Basic Authentication (Remote)
 
 Set `*BasicAuthPasswordIdentityProvider*` in the `*identityProviders*` stanza to
 validate user names and passwords against a remote server using a
@@ -237,7 +247,9 @@ configured URL.
 <7> Key for the client certificate. Required if `*certFile*` is specified.
 ====
 
-=== Request Header [[RequestHeaderIdentityProvider]]
+[[RequestHeaderIdentityProvider]]
+
+=== Request Header
 
 Set `*RequestHeaderIdentityProvider*` in the `*identityProviders*` stanza to
 identify users from request header values, such as `X-Remote-User`. It is
@@ -508,7 +520,9 @@ perhaps run `kdestroy` in the case of Kerberos.
 
 ====
 
-=== GitHub [[GitHub]]
+[[GitHub]]
+
+=== GitHub
 
 Set `*GitHubIdentityProvider*` in the `*identityProviders*` stanza to use
 https://github.com/[GitHub] as an identity provider, using the
@@ -545,7 +559,9 @@ application]. The application must be configured with a callback URL of
 <5> The client secret issued by GitHub.
 ====
 
-=== Google [[Google]]
+[[Google]]
+
+=== Google
 
 Set `*GoogleIdentityProvider*` in the `*identityProviders*` stanza to use Google as
 an identity provider, using
@@ -588,7 +604,9 @@ domain] to restrict sign-in accounts to. If empty, any Google account is allowed
 to authenticate.
 ====
 
-=== OpenID Connect [[OpenID]]
+[[OpenID]]
+
+=== OpenID Connect
 
 Set `*OpenIDIdentityProvider*` in the `*identityProviders*` stanza to integrate with
 an OpenID Connect identity provider using an
@@ -727,6 +745,8 @@ for this identity. First non-empty claim is used.
 Endpoint] described in the OpenID spec. Must use `https`.
 ====
 
+[[token-options]]
+
 == Token Options
 
 The OAuth server generates two kinds of tokens:
@@ -754,6 +774,8 @@ The default lifetime is 24 hours.
 codes. The default lifetime is five minutes.
 ====
 
+[[grant-options]]
+
 == Grant Options
 
 To configure how the OAuth server responds to token requests for a client the
@@ -776,6 +798,8 @@ oauthConfig:
 ----
 ====
 
+[[session-options]]
+
 == Session Options
 
 The OAuth server uses a signed and encrypted cookie-based session during login

admin_guide/install/docker_registry.adoc

@@ -50,6 +50,8 @@ To see a full list of options that you can specify when creating the registry:
 $ oadm registry --help
 ----
 
+[[storage-for-the-registry]]
+
 === Storage for the Registry
 
 The registry stores Docker images and metadata. If you simply deploy a pod with
@@ -114,6 +116,8 @@ $ oadm registry --service-account=registry \
     --mount-host=<path>
 ----
 
+[[viewing-logs]]
+
 == Viewing Logs
 
 To view the logs for the Docker registry, run the `oc logs` command for the
@@ -131,6 +135,8 @@ $ oc logs docker-registry-1-da73t
 ----
 ====
 
+[[file-storage]]
+
 == File Storage
 
 Tag and image metadata is stored in OpenShift, but the registry owns layer and

admin_guide/install/first_steps.adoc

@@ -25,6 +25,8 @@ If you opted out of creating them during an link:advanced_install.html[advanced
 installation], you can use the following instructions to create the objects
 yourself. The files are installed on the file system of your master.
 
+[[prerequisites]]
+
 == Prerequisites
 - You installed OpenShift Enterprise using either the
 link:quick_install.html[quick installation] or
@@ -36,6 +38,8 @@ link:../../architecture/additional_concepts/authorization.html#roles[*cluster-ad
 privileges], because they operate on the default *openshift*
 link:../../architecture/core_concepts/projects_and_users.html#projects[project].
 
+[[creating-image-streams-for-openshift-images]]
+
 == Creating Image Streams for OpenShift Images
 The core set of image streams provide images that can be used to build
 link:../../using_images/s2i_images/nodejs.html[*Node.js*],
@@ -93,6 +97,8 @@ Access to the images referenced by these image streams requires the relevant xPa
 ====
 endif::[]
 
+[[creating-database-service-templates]]
+
 == Creating Database Service Templates
 The database service templates make it easy to run a database image which can be
 utilized by other components. For each database
@@ -119,6 +125,8 @@ $ oc create -f \
 After creating the templates, users are able to easily instantiate the various
 templates, giving them quick access to a database deployment.
 
+[[creating-quickstart-templates]]
+
 == Creating QuickStart Templates
 The QuickStart templates define a full set of objects for a running application.
 These include:
@@ -182,6 +190,8 @@ for demonstration purposes only as all database data will be lost if the databas
 
 endif::[]
 
+[[what's-next]]
+
 == What's Next?
 
 With these artifacts created, developers can now

admin_guide/manage_authorization_policy.adoc

@@ -16,6 +16,8 @@ policies] and the administrator CLI to manage the
 link:../architecture/additional_concepts/authorization.html[roles and bindings]
 within a policy.
 
+[[viewing-roles-and-bindings]]
+
 == Viewing Roles and Bindings
 link:../architecture/additional_concepts/authorization.html#roles[Roles] grant
 various levels of access in the system-wide
@@ -35,6 +37,8 @@ the *admin*
 link:../architecture/additional_concepts/authorization.html#roles[default role]
 in a given local policy can view that project-scoped policy.
 
+[[viewing-cluster-policy]]
+
 === Viewing Cluster Policy
 To view the cluster roles and their associated rule sets in the cluster policy:
 
@@ -229,6 +233,8 @@ RoleBinding[system:webhooks]:
 ----
 ====
 
+[[viewing-local-policy]]
+
 === Viewing Local Policy
 
 While the list of local roles and their associated rule sets are not viewable
@@ -286,6 +292,8 @@ immediately listed. However, if other
 link:../architecture/additional_concepts/authorization.html#roles[default roles]
 are added to users and groups within a local policy, they become listed as well.
 
+[[managing-role-bindings]]
+
 == Managing Role Bindings
 Adding, or _binding_, a
 link:../architecture/additional_concepts/authorization.html#roles[role] to

admin_guide/manage_scc.adoc

@@ -15,6 +15,8 @@ You can manage
 link:../architecture/additional_concepts/authorization.html#security-context-constraints[security context constraints]
 in your instance via the `oc` command as a normal API objects.
 
+[[listing-security-context-constraints]]
+
 == Listing Security Context Constraints
 
 [options="nowrap"]
@@ -25,6 +27,8 @@ privileged   true      []        true      RunAsAny    RunAsAny
 restricted   false     []        false     MustRunAs   MustRunAsRange
 ----
 
+[[creating-new-security-context-constraints]]
+
 == Creating New Security Context Constraints
 
 Creating a new SCC is accomplished with the `oc create` command.  First, define the SCC in a json
@@ -55,6 +59,8 @@ restricted   false     []        false     MustRunAs   MustRunAsRange
 scc-admin    true      []        false     RunAsAny    RunAsAny
 ----
 
+[[deleting-security-context-constraints]]
+
 == Deleting Security Context Constraints
 
 [options="nowrap"]
@@ -67,15 +73,21 @@ NOTE: If you delete the default security context constraints they will not be re
 restart unless you delete all security context constraints.  If any constraint already exists
 within the system, no generation will take place.
 
+[[updating-security-context-constraints]]
+
 == Updating Security Context Constraints
 
 [options="nowrap"]
 ----
 $ oc edit scc privileged
 ----
 
+[[how-do-i]]
+
 == How Do I?
 
+[[grant--access-to-the-privileged-scc]]
+
 === Grant Access to the Privileged SCC
 
 In some cases, an administrator might want to allow users or groups outside the
@@ -124,6 +136,8 @@ users:
 
 ====
 
+[[enable-images-to-run-with-user-in-the-dockerfile]]
+
 === Enable Images to Run with USER in the Dockerfile
 
 To relax the security in your cluster so that images are not forced to run as a
@@ -144,6 +158,8 @@ This allows images to run as the root UID if no *USER* is specified in the
 Dockerfile.
 ====
 
+[[use-mount-host-on-the-registry]]
+
 === Use `--mount-host` on the Registry
 
 It is recommended that persistent volumes be used for registry deployments. If

admin_guide/master_node_configuration.adoc

@@ -32,6 +32,8 @@ remember all of the options to specify. To make this easier, the configuration
 files can be created with the `--write-config` option and then used with the
 `--config` option.
 
+[[creating-new-configuration-files]]
+
 == Creating New Configuration Files
 For masters, the `openshift start` command accepts options that indicate that it
 should simply write the configuration files that it would have used, then
@@ -74,6 +76,8 @@ above command also assumes that certificate files are located in an
 options to specify their location. Run the command with the `-h` option to see
 details.
 
+[[launching-servers-using-configuration-files]]
+
 == Launching Servers Using Configuration Files
 Once you have modified the master and/or node configuration files to your
 specifications, you can use them when launching servers by specifying them as an
@@ -102,6 +106,8 @@ To launch a node server using a node configuration file:
 $ openshift start node --config=/openshift.local.config/node-<node_hostname>/node-config.yaml
 ----
 
+[[master-configuration-files]]
+
 == Master Configuration Files
 The following *_master-config.yaml_* file is a sample master configuration
 file taken at a point in time. You can
@@ -237,6 +243,8 @@ servingInfo:
   requestTimeoutSeconds: 3600
 ----
 
+[[node-configuration-files]]
+
 == Node Configuration Files
 
 The following *_node-config.yaml_* file is a sample node configuration file