adding file back but removed from conf doc

Signed-off-by: Carol Fager-Higgins <carol.fager-higgins@docker.com>

configuration.md

@@ -1,4 +1,3 @@
-
 +++
 title = "Configuration options"
 description = "Configuration instructions for Docker Trusted Registry"
@@ -11,36 +10,46 @@ weight=5
 
 # Configuring Docker Trusted Registry
 
-## Overview
-
-Use this documentation to  configure Docker Trusted Registry  so it can
+Use this documentation to configure Docker Trusted Registry so it can
 run in your environment.
 
-Start with Docker Trusted Registry loaded in your browser and select  "Settings" in the global nav
-bar at the top of the page to view configuration options. You see menus
-organizing the options for configuring:
+## Overview
+
+To start, navigate to the Trusted Registry user interface (UI) > Settings to view configuration options. Configuring is grouped by the following:
 
 * General Settings (for example, ports and proxies)
 * Security settings
 * Storage settings
-* Your Docker Trusted Registry license
+* License
 * Authentication settings
+* Garbage collection
+* Updates
 
-> **Note:**
-> Saving changes you've made to settings may restart various services, as follows:
-> * General settings: full Docker Trusted Registry restart
-> * License change: full Docker Trusted Registry restart
-> * SSL change: Nginx reload
-> * Storage config: only registries restart
-> * Authentication config: no restart
+ **Note**:
+ Saving changes you've made to settings may restart various services, as follows:
 
+ * General settings: full Docker Trusted Registry restart
+ * License change: full Docker Trusted Registry restart
+ * SSL change: Nginx reload
+ * Storage config: only registries restart
+ * Authentication config: no restart
 
 ## General Settings
 
 ![Domain and Ports page</admin/settings#http>](assets/admin-settings.png)
 
+
 Each setting on this page is explained in the Docker Trusted Registry UI.
 
+* Domain Name*: **required** defaults to an empty string, the fully qualified domain name assigned to the Docker Trusted Registry host.
+* HTTP Port*: defaults to 80, used as the entry point for the image storage service. To see load balancer status, you can query
+http://&lt;dtr-host&gt;/load_balancer_status.
+* HTTPS Port*: defaults to 443, used as the secure entry point for the image storage service.
+* HTTP proxy*: defaults to an empty string, proxy server for HTTP requests.
+* HTTPS proxy*: defaults to an empty string, proxy server for HTTPS requests.
+* No proxy*: defaults to an empty string, proxy bypass for HTTP and HTTPS requests.
+* Upgrade checking*: enables or disables automatic checking for Docker Trusted Registry software updates.
+
 > **Note**: If you need Docker Trusted Registry to re-generate a self-signed certificate at some
 > point, you can change the domain name. Whenever the domain name does not match the current certificate,
 > a new self-signed certificate will be generated for the new domain. This also works with IP addresses.
@@ -96,13 +105,13 @@ In order to run, Docker Trusted Registry requires encrypted communications via H
 If you are generating your own certificates, you can install them by following the instructions for
 [Adding your own registry certificates to Docker Trusted Registry](#adding-your-own-registry-certificates-to-dtr).
 
-On the other hand, if you choose to use the Docker Trusted Registry-generated certificates, or the
-certificates you generate yourself are not trusted by your client Docker hosts,
-you will need to do one of the following:
+However, if you choose to use the Trusted Registry-generated certificates, or
+the certificates you generate yourself are not trusted by your client Docker
+hosts, you will need to do one of the following:
 
-* [Install a registry certificate on all of your client Docker daemons](#installing-registry-certificates-on-client-docker-daemons),
+* [Install](#installing-registry-certificates-on-client-docker-daemons) a registry certificate on all of your client Docker daemons
 
-* Set your [client Docker daemons to run with an unconfirmed connection to the registry](#if-you-can-t-install-the-certificates).
+* Set your [client Docker daemons](#if-you-can-t-install-the-certificates) to run with an unconfirmed connection to the registry.
 
 ### Generating SSL certificates
 
@@ -119,35 +128,36 @@ certificate. If your certificates are generated using a globally trusted
 Certificate Authority, you won't need to install them on all of your
 client Docker daemons.
 
-3. Use the self-signed registry certificate generated by Docker Trusted Registry, and install it
-onto the client Docker daemon hosts as shown below.
+3. Use the self-signed registry certificate generated by Docker Trusted
+Registry, and install it onto the client Docker daemon hosts as seen in the
+following section.
 
 ### Adding your own Registry certificates to Docker Trusted Registry
 
-Whichever method you use to generate certificates, once you have them
-you can set up your Docker Trusted Registry server to use them by navigating to the "Settings" page,
-going to "Security," and putting the SSL Certificate text (including all
-intermediate Certificates, starting with the host) into the
-"SSL Certificate" edit box, and the previously generated Private key into
-the "SSL Private Key" edit box.
+Whichever method you use to generate certificates, once you have them you can
+set up your Docker Trusted Registry server to use them by navigating to the
+"Settings" page, going to "Security," and putting the SSL Certificate text
+(including all intermediate Certificates, starting with the host) into the "SSL
+Certificate" edit box, and the previously generated Private key into the "SSL
+Private Key" edit box.
 
-Click the "Save" button, and then wait for the Docker Trusted Registry Admin site to restart and
-reload. It should now be using the new certificate.
+Click  Save, and then wait for the Docker Trusted Registry Admin site to restart
+and reload. It should now be using the new certificate.
 
-Once the "Security" page has reloaded, it will show `#` hashes instead of the
+Once the "Security" page has reloaded, it shows `#` hashes instead of the
 certificate text you pasted in.
 
 If your certificate is signed by a chain of Certificate Authorities that are
-already trusted by your Docker daemon servers, you can skip the "Installing
-registry certificates" step below.
+already trusted by your Docker daemon servers, you can skip the following
+"Installing registry certificates" step.
 
 ### Installing Registry certificates on client Docker daemons
 
 If your certificates do not have a trusted Certificate Authority, you will need
 to install them on each client Docker daemon host.
 
-The procedure for installing the Docker Trusted Registry certificates on each Linux distribution has
-slightly different steps, as shown below.
+The procedure for installing the Docker Trusted Registry certificates on each
+Linux distribution has slightly different steps.
 
 You can test this certificate using `curl`:
 
@@ -306,16 +316,23 @@ API](http://docs.docker.com/registry/storagedrivers/#storage-driver-api).
 
 ![Storage settings page</admin/settings#storage>](assets/admin-settings-storage.png)
 
-After you select the image storage method you would like to use from the drop-down menu
-near the top of the page, the UI will change to reflect the configuration settings
-appropriate to the selected method.
+After you select the image storage method you would like to use from the
+drop-down menu near the top of the page, the UI changes to reflect the
+configuration settings appropriate to the selected method. You can either use
+the storage specific input boxes to configure the most common settngs for local
+filesystem, S3, or Azure storage backends, or use the full Yaml configuration
+file upload to have more detailed control.
 
-You can either use the storage specific input boxes to configure the most common settngs
-for local filesystem, S3, or Azure storage backends,
-or use the full Yaml configuration file upload to have more detailed control.
 
-You can view the current `storage.yaml` file on your Docker Trusted Registry Docker host in the `/usr/local/etc/dtr/`
-directory.
+You can either use the storage specific input boxes to configure the most common
+settngs for local filesystem, S3, or Azure storage backends, or use the full
+Yaml configuration file upload to have more detailed control.
+
+**Note**: Changing your storage backend requires you to restart the Trusted Registry.
+
+
+You can view the current `storage.yaml` file on your Docker Trusted Registry
+Docker host in the `/usr/local/etc/dtr/` directory.
 
 ### Filesystem settings
 
@@ -331,23 +348,26 @@ The [S3 storage backend](/registry/configuration/#s3) page allows you to set the
 
 ### Azure settings
 
-The [Azure storage backend](/registry/configuration/#azure) page allows you to set
-the "Account name", "Account key", "Container", and "Realm".
+Set the "Account name", "Account key", "Container", and "Realm" on the [Azure storage backend](/registry/configuration/#azure) page.
+
+<!--  remove for 1.4. will most likely be in a later release.
+### Openstack Swift settings
+
+View the [openstack Swift settings](/registry/configuration/#openstack-swift) documentation so that you can set up your storage settings:
+authurl, username, password, container, tenant, tenantid, domain, domainid, insecureskipverify, region, chunksize, and prefix.
+-- >
 
 ### Yaml configuration file
 
-If the Quick setup options above are not sufficient to configure your Registry
-options, you can upload a YAML file.
-
-The schema of this file is identical to that used
-by the [Registry](http://docs.docker.com/registry/configuration/).
+If the previous Quick setup options are not sufficient to configure your
+Registry options, you can upload a YAML file. The schema of this file is
+identical to that used by the [Registry](http://docs.docker.com/registry/configuration/).
 
 * If you are using the file system driver to provide local image storage, you
   will need to specify a root directory which will get mounted as a sub-path of
   `/var/local/dtr/image-storage`. The default value of this root directory is
   `/local`, so the full path to it is `/var/local/dtr/image-storage/local`.
 
-
 ## Authentication
 
 Use the  "Authentication" settings to control access
@@ -360,8 +380,9 @@ The current authentication methods are `None`, `Managed` and `LDAP`.
 
 ### No authentication
 
-No authentication means that everyone that can access your Docker Trusted Registry web administration
-site. This is not recommended for any use other than testing.
+No authentication means that everyone that can access your Docker Trusted
+Registry web administration site. This is not recommended for any use other than
+testing.
 
 ### Managed authentication
 
@@ -371,13 +392,11 @@ The "read-only" role can pull all images from the registry, "read-write" can
 push and pull all images, and the "admin" role can push and pull and also access
 the web administration UI and metrics dashboard.
 
-When you create users and assign their roles via the API, you do not need
-to assign those users roles using the Docker Trusted Registry admin web UI.
+When you create users and assign their roles through the API, you do not need
+to assign those users roles using the Docker Trusted Registry admin UI.
 
-![Managed authentication settings page</admin/settings#auth>](assets/admin-settings-authentication-basic.png)
-
-* Choose the appropriate button to add one user, or to upload a CSV file containing username,
-  password pairs, and selection boxes for "admin", "read-write", and "read-only" roles.
+* Choose the appropriate button to add one user, or to upload a CSV file containing username, password pairs, and selection boxes for "admin",
+"read-write", and "read-only" roles.
 * You can also create, or allow others to create the username, password pair using the
  [Account API](/docker-trusted-registry/api/dtr_1_3_accounts/#create-an-account)
 
@@ -386,27 +405,28 @@ to assign those users roles using the Docker Trusted Registry admin web UI.
 Using LDAP authentication allows you to integrate your Docker Trusted Registry into your
 organization's existing LDAP user and authentication database.
 
-To improve the performance of Docker Trusted Registry's Access Control Lists, User and Group
-membership data is synced into Docker Trusted Registry's database at a configurable *LDAP Sync
-Interval*. User passwords are not transferred during syncing; Docker Trusted Registry will defer to the LDAP server to validate username/password pairs.
+To improve the performance of Docker Trusted Registry's Access Control Lists,
+User and Group membership data is synced into Docker Trusted Registry's database
+at a configurable *LDAP Sync Interval*. User passwords are not transferred
+during syncing.  The Trusted Registry defers to the LDAP server to validate
+username/password pairs.
 
 > **Note**: LDAP syncing does not create new user accounts or teams in Docker Trusted Registry. It
 > will only manage existing teams that have been specified to sync with LDAP.
 > Use the [Docker Trusted Registry APIs](/docker-trusted-registry/api/) to create new users and
 > teams from your LDAP server.
 
-You can configure the "userFilter" to select the set of users that are candidates
-for each of the "admin", global "read-write", and global "read-only" roles. Unlike "Managed"
-authentication, the "admin" role is separate from the registry access roles, so
-LDAP users in the "admin" role won't have access to Docker Trusted Registry images unless they are
-also given the "read-write" or "read-only" role.
+You can configure the "userFilter" to select the set of users that are
+candidates for each of the "admin", global "read-write", and global "read-only"
+roles. Unlike "Managed" authentication, the "admin" role is separate from the
+registry access roles, so LDAP users in the "admin" role won't have access to
+Docker Trusted Registry images unless they are also given the "read-write" or
+"read-only" role.
 
 Alternativly, you can assign
 [Organization, Team or User repository roles using the API](/docker-trusted-registry/api/).
 
-Because connecting to LDAP involves existing infrastructure external to Docker Trusted Registry and
-Docker, you need to gather the details required to configure Docker Trusted Registry for your
-organization's particular LDAP implementation.
+Because connecting to LDAP involves existing infrastructure external to Docker Trusted Registry and Docker, you need to gather the details required to configure Docker Trusted Registry for your organization's particular LDAP implementation.
 
 You can test that you have the correct LDAP server information by connecting to
 the LDAP server from inside a Docker container running on the same server as
@@ -426,13 +446,14 @@ Or if the LDAP server is set up to allow anonymous access (which means your
 docker run --rm -it svendowideit/ldapsearch -h <LDAP Server hostname> -b <User Base DN> -x
 ```
 
-The result of these queries should be a (very) long list - if you get an authentication error,
-then the details you have are not sufficient - contact your organization's LDAP team.
+The result of these queries should be a (very) long list - if you get an
+authentication error, then the details you have are not sufficient - contact
+your organization's LDAP team.
 
-The *User Login Attribute* key setting must match the field used in the LDAP server
-for the user's login-name. On OpenLDAP, it's generally `uid`, and on Microsoft Active Directory
-servers, it's `sAMAccountName`. The `ldapsearch` output above should allow you to
-confirm which setting you need.
+The *User Login Attribute* key setting must match the field used in the LDAP
+server for the user's login-name. On OpenLDAP, it's generally `uid`, and on
+Microsoft Active Directory servers, it's `sAMAccountName`. The `ldapsearch`
+output should allow you to confirm which setting you need.
 
 ![LDAP authentication settings page</admin/settings#auth>](assets/admin-settings-authentication-ldap.png)
 
@@ -454,11 +475,11 @@ confirm which setting you need.
 * * *Read-Only Role Filter*: Combined with the "User Filter" to specify users permitted to
     pull images from Docker Trusted Registry
 
-> **Note**: While the "role" filters are optional, keep in mind that if they are
+> **Note**: While the "role" filters are optional, remember that if they are
 > left empty, all users will get those full privileges. In other words, if the
 > "admin" filter is left empty, all users will get admin privileges, if the
-> "read-write" filter is empty, all users can push/pull any image, etc. (This
-> behavior will be corrected in future versions.)
+> "read-write" filter is empty, all users can push/pull any image, and so forth.
+> (This behavior may change in future versions.)
 
 #### Confirm login with current configuration
 
@@ -466,5 +487,4 @@ You can test your current LDAP configuration before saving it by entering a test
 
 ## Next Steps
 
-For information on getting support for Docker Trusted Registry, take a look at the
-[Support information](support.md).
+For information on getting support for Docker Trusted Registry, go to [Support information](support.md).