Merge pull request #1340 from docker/master

merging master to the patch release branch

compose/extends.md

@@ -62,7 +62,7 @@ services.
 
     web:
       image: example/my_web_app:latest
-      links:
+      depends_on:
         - db
         - cache
 
@@ -136,7 +136,7 @@ Start with a **docker-compose.yml**.
 
     web:
       image: example/my_web_app:latest
-      links:
+      depends_on:
         - db
 
     db:
@@ -147,7 +147,7 @@ export or backup.
 
     dbadmin:
       build: database_admin/
-      links:
+      depends_on:
         - db
 
 To start a normal environment run `docker-compose up -d`. To run a database
@@ -177,9 +177,9 @@ is useful if you have several services that reuse a common set of configuration
 options. Using `extends` you can define a common set of service options in one
 place and refer to it from anywhere.
 
-Keep in mind that `links`, `volumes_from`, and `depends_on` are never shared
+Keep in mind that `volumes_from` and `depends_on` are never shared between
-between services using `extends`. These exceptions exist to avoid implicit
+services using `extends`. These exceptions exist to avoid implicit
-dependencies; you always define `links` and `volumes_from` locally. This ensures
+dependencies; you always define `volumes_from` locally. This ensures
 dependencies between services are clearly visible when reading the current file.
 Defining these locally also ensures that changes to the referenced file don't
 break anything.
@@ -233,7 +233,7 @@ You can also write other services and link your `web` service to them:
       environment:
         - DEBUG=1
       cpu_shares: 5
-      links:
+      depends_on:
         - db
     db:
       image: postgres
@@ -264,7 +264,7 @@ common configuration:
       command: /code/run_web_app
       ports:
         - 8080:8080
-      links:
+      depends_on:
         - queue
         - db
 
@@ -273,7 +273,7 @@ common configuration:
         file: common.yml
         service: app
       command: /code/run_worker
-      links:
+      depends_on:
         - queue
 
 ## Adding and overriding configuration

ee/dtr/admin/install/index.md

@@ -79,7 +79,7 @@ the install command on. DTR will be installed on the UCP worker defined by the
     automatically reconfigured to trust DTR.
 
     * With DTR 2.7, you can [enable browser authentication via client
-    certificates](/ee/enable-authentication-via-client-certificates/) at install
+    certificates](/ee/enable-client-certificate-authentication/) at install
     time. This bypasses the DTR login page and hides the logout button, thereby
     skipping the need for entering your username and password.
 

ee/ucp/admin/install/upgrade.md

@@ -356,4 +356,4 @@ From UCP 2.0: UCP 2.0 -> UCP 2.1 -> UCP 2.2
 
 ## Where to go next
 
-- [Upgrade DTR](/e/dtr/admin/upgrade/)
+- [Upgrade DTR](/ee/dtr/admin/upgrade/)

network/iptables.md

@@ -53,9 +53,9 @@ for a lot more information.
 
 ## Prevent Docker from manipulating iptables
 
-To prevent Docker from manipulating the `iptables` policies at all, set the
+It is possible to set the `iptables` key to `false` in the Docker engine's configuration file at `/etc/docker.daemon.json`, but this option is not appropriate for most users.  It is not possible to completely prevent Docker from creating `iptables` rules, and creating them after-the-fact is extremely involved and beyond the scope of these instructions.  Setting `iptables` to `false` will more than likely break container networking for the Docker engine.
-`iptables` key to `false` in `/etc/docker/daemon.json`. This is inappropriate
+
-for most users, because the `iptables` policies then need to be managed by hand.
+For system integrators who wish to build the Docker runtime into other applications, explore the [`moby` project](https://mobyproject.org/).
 
 ## Next steps