7 files changed, 162 insertions, 48 deletions
diff --git a/docs/sources/articles/cfengine_process_management.md b/docs/sources/articles/cfengine_process_management.md
index ee5ba238a0..6bb4df66ae 100644
--- a/docs/sources/articles/cfengine_process_management.md
+++ b/docs/sources/articles/cfengine_process_management.md
@@ -87,7 +87,7 @@ The first two steps can be done as part of a Dockerfile, as follows.
     ENTRYPOINT ["/var/cfengine/bin/docker_processes_run.sh"]
 
 By saving this file as Dockerfile to a working directory, you can then build
-your image with the docker build command, e.g.
+your image with the docker build command, e.g.,
 `docker build -t managed_image`.
 
 ### Testing the container
diff --git a/docs/sources/articles/dsc.md b/docs/sources/articles/dsc.md
new file mode 100644
index 0000000000..94f5e9d4db
--- /dev/null
+++ b/docs/sources/articles/dsc.md
@@ -0,0 +1,117 @@
+page_title: PowerShell DSC Usage
+page_description: Using DSC to configure a new Docker host
+page_keywords: powershell, dsc, installation, usage, docker, documentation
+
+# Using PowerShell DSC
+
+Windows PowerShell Desired State Configuration (DSC) is a configuration
+management tool that extends the existing functionality of Windows PowerShell.
+DSC uses a declarative syntax to define the state in which a target should be
+configured. More information about PowerShell DSC can be found at
+http://technet.microsoft.com/en-us/library/dn249912.aspx.
+
+## Requirements
+
+To use this guide you'll need a Windows host with PowerShell v4.0 or newer.
+
+The included DSC configuration script also uses the official PPA so
+only an Ubuntu target is supported. The Ubuntu target must already have the
+required OMI Server and PowerShell DSC for Linux providers installed. More
+information can be found at https://github.com/MSFTOSSMgmt/WPSDSCLinux. The
+source repository listed below also includes PowerShell DSC for Linux
+installation and init scripts along with more detailed installation information.
+
+## Installation
+
+The DSC configuration example source is available in the following repository:
+https://github.com/anweiss/DockerClientDSC. It can be cloned with:
+
+    $ git clone https://github.com/anweiss/DockerClientDSC.git
+
+## Usage
+
+The DSC configuration utilizes a set of shell scripts to determine whether or
+not the specified Docker components are configured on the target node(s). The
+source repository also includes a script (`RunDockerClientConfig.ps1`) that can
+be used to establish the required CIM session(s) and execute the
+`Set-DscConfiguration` cmdlet.
+
+More detailed usage information can be found at
+https://github.com/anweiss/DockerClientDSC.
+
+### Run Configuration
+The Docker installation configuration is equivalent to running:
+
+```
+apt-get install docker.io
+ln -sf /usr/bin/docker.io /usr/local/bin/docker
+sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io
+```
+
+Ensure that your current working directory is set to the `DockerClientDSC`
+source and load the DockerClient configuration into the current PowerShell
+session
+
+```powershell
+. .\DockerClient.ps1
+```
+
+Generate the required DSC configuration .mof file for the targeted node
+
+```powershell
+DockerClient -Hostname "myhost"
+```
+
+A sample DSC configuration data file has also been included and can be modified
+and used in conjunction with or in place of the `Hostname` parameter:
+
+```powershell
+DockerClient -ConfigurationData .\DockerConfigData.psd1
+```
+
+Start the configuration application process on the targeted node
+
+```powershell
+.\RunDockerClientConfig.ps1 -Hostname "myhost"
+```
+
+The `RunDockerClientConfig.ps1` script can also parse a DSC configuration data
+file and execute configurations against multiple nodes as such:
+
+```powershell
+.\RunDockerClientConfig.ps1 -ConfigurationData .\DockerConfigData.psd1
+```
+
+### Images
+Image configuration is equivalent to running: `docker pull [image]`.
+
+Using the same Run Configuration steps defined above, execute `DockerClient`
+with the `Image` parameter:
+
+```powershell
+DockerClient -Hostname "myhost" -Image node
+```
+
+The configuration process can be initiated as before:
+
+```powershell
+.\RunDockerClientConfig.ps1 -Hostname "myhost"
+```
+
+### Containers
+Container configuration is equivalent to running:
+`docker run -d --name="[containername]" [image] '[command]'`.
+
+Using the same Run Configuration steps defined above, execute `DockerClient`
+with the `Image`, `ContainerName`, and `Command` parameters:
+
+```powershell
+DockerClient -Hostname "myhost" -Image node -ContainerName "helloworld" `
+-Command 'echo "Hello World!"'
+```
+
+The configuration process can be initiated as before:
+
+```powershell
+.\RunDockerClientConfig.ps1 -Hostname "myhost"
+```
diff --git a/docs/sources/articles/https.md b/docs/sources/articles/https.md
index cc8c6a9761..b6ae4ef37d 100644
--- a/docs/sources/articles/https.md
+++ b/docs/sources/articles/https.md
@@ -29,7 +29,7 @@ keys:
     $ openssl req -new -x509 -days 365 -key ca-key.pem -out ca.pem
 
 Now that we have a CA, you can create a server key and certificate
-signing request. Make sure that "Common Name (e.g. server FQDN or YOUR
+signing request. Make sure that "Common Name (e.g., server FQDN or YOUR
 name)" matches the hostname you will use to connect to Docker or just
 use `\*` for a certificate valid for any hostname:
 
diff --git a/docs/sources/articles/networking.md b/docs/sources/articles/networking.md
index 927cd80875..bf46b90ea2 100644
--- a/docs/sources/articles/networking.md
+++ b/docs/sources/articles/networking.md
@@ -26,7 +26,7 @@ bridge* that automatically forwards packets between any other network
 interfaces that are attached to it.  This lets containers communicate
 both with the host machine and with each other.  Every time Docker
 creates a container, it creates a pair of “peer” interfaces that are
-like opposite ends of a pipe — a packet send on one will be received on
+like opposite ends of a pipe — a packet sent on one will be received on
 the other.  It gives one of the peers to the container to become its
 `eth0` interface and keeps the other peer, with a unique name like
 `vethAQI2QT`, out in the namespace of the host machine.  By binding
diff --git a/docs/sources/articles/runmetrics.md b/docs/sources/articles/runmetrics.md
index bf4fe21c4e..9c871a24f6 100644
--- a/docs/sources/articles/runmetrics.md
+++ b/docs/sources/articles/runmetrics.md
@@ -35,7 +35,7 @@ known to the system, the hierarchy they belong to, and how many groups they cont
 
 You can also look at `/proc/<pid>/cgroup` to see which control groups a process
 belongs to. The control group will be shown as a path relative to the root of
-the hierarchy mountpoint; e.g. `/` means “this process has not been assigned into
+the hierarchy mountpoint; e.g., `/` means “this process has not been assigned into
 a particular group”, while `/lxc/pumpkin` means that the process is likely to be
 a member of a container named `pumpkin`.
 
@@ -106,9 +106,9 @@ to the processes within the cgroup, excluding sub-cgroups. The second half
 (with the `total_` prefix) includes sub-cgroups as well.
 
 Some metrics are "gauges", i.e. values that can increase or decrease
-(e.g. swap, the amount of swap space used by the members of the cgroup).
+(e.g., swap, the amount of swap space used by the members of the cgroup).
 Some others are "counters", i.e. values that can only go up, because
-they represent occurrences of a specific event (e.g. pgfault, which
+they represent occurrences of a specific event (e.g., pgfault, which
 indicates the number of page faults which happened since the creation of
 the cgroup; this number can never decrease).
 
@@ -410,7 +410,7 @@ used.
 
 Docker makes this difficult because it relies on `lxc-start`, which
 carefully cleans up after itself, but it is still possible. It is
-usually easier to collect metrics at regular intervals (e.g. every
+usually easier to collect metrics at regular intervals (e.g., every
 minute, with the collectd LXC plugin) and rely on that instead.
 
 But, if you'd still like to gather the stats when a container stops,
diff --git a/docs/sources/articles/security.md b/docs/sources/articles/security.md
index cdf5fdddd0..dcc61f386c 100644
--- a/docs/sources/articles/security.md
+++ b/docs/sources/articles/security.md
@@ -5,7 +5,7 @@ page_keywords: Docker, Docker documentation, security
 # Docker Security
 
 > *Adapted from* [Containers & Docker: How Secure are
-> They?](http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/)
+> They?](http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/)
 
 There are three major areas to consider when reviewing Docker security:
 
@@ -17,15 +17,10 @@ There are three major areas to consider when reviewing Docker security:
 
 ## Kernel Namespaces
 
-Docker containers are essentially LXC containers, and they come with the
-same security features. When you start a container with
-`docker run`, behind the scenes Docker uses
-`lxc-start` to execute the Docker container. This
-creates a set of namespaces and control groups for the container. Those
-namespaces and control groups are not created by Docker itself, but by
-`lxc-start`. This means that as the LXC userland
-tools evolve (and provide additional namespaces and isolation features),
-Docker will automatically make use of them.
+Docker containers are very similar to LXC containers, and they come with
+the similar security features. When you start a container with `docker
+run`, behind the scenes Docker creates a set of namespaces and control
+groups for the container.
 
 **Namespaces provide the first and most straightforward form of
 isolation**: processes running within a container cannot see, and even
@@ -55,10 +50,9 @@ ago), namespace code has been exercised and scrutinized on a large
 number of production systems. And there is more: the design and
 inspiration for the namespaces code are even older. Namespaces are
 actually an effort to reimplement the features of [OpenVZ](
-http://en.wikipedia.org/wiki/OpenVZ) in such a way that they
-could be merged within the mainstream kernel. And OpenVZ was initially
-released in 2005, so both the design and the implementation are pretty
-mature.
+http://en.wikipedia.org/wiki/OpenVZ) in such a way that they could be
+merged within the mainstream kernel. And OpenVZ was initially released
+in 2005, so both the design and the implementation are pretty mature.
 
 ## Control Groups
 
@@ -82,7 +76,7 @@ started in 2006, and initially merged in kernel 2.6.24.
 ## Docker Daemon Attack Surface
 
 Running containers (and applications) with Docker implies running the
-Docker daemon. This daemon currently requires root privileges, and you
+Docker daemon. This daemon currently requires `root` privileges, and you
 should therefore be aware of some important details.
 
 First of all, **only trusted users should be allowed to control your
@@ -97,8 +91,8 @@ without any restriction. This sounds crazy? Well, you have to know that
 same way**. Nothing prevents you from sharing your root filesystem (or
 even your root block device) with a virtual machine.
 
-This has a strong security implication: if you instrument Docker from
-e.g. a web server to provision containers through an API, you should be
+This has a strong security implication: for example, if you instrument Docker
+from a web server to provision containers through an API, you should be
 even more careful than usual with parameter checking, to make sure that
 a malicious user cannot pass crafted parameters causing Docker to create
 arbitrary containers.
@@ -114,8 +108,9 @@ socket.
 You can also expose the REST API over HTTP if you explicitly decide so.
 However, if you do that, being aware of the above mentioned security
 implication, you should ensure that it will be reachable only from a
-trusted network or VPN; or protected with e.g. `stunnel`
-and client SSL certificates.
+trusted network or VPN; or protected with e.g., `stunnel` and client SSL
+certificates. You can also secure them with [HTTPS and
+certificates](/articles/https/).
 
 Recent improvements in Linux namespaces will soon allow to run
 full-featured containers without root privileges, thanks to the new user
@@ -141,7 +136,7 @@ Finally, if you run Docker on a server, it is recommended to run
 exclusively Docker in the server, and move all other services within
 containers controlled by Docker. Of course, it is fine to keep your
 favorite admin tools (probably at least an SSH server), as well as
-existing monitoring/supervision processes (e.g. NRPE, collectd, etc).
+existing monitoring/supervision processes (e.g., NRPE, collectd, etc).
 
 ## Linux Kernel Capabilities
 
@@ -159,8 +154,8 @@ This means a lot for container security; let's see why!
 
 Your average server (bare metal or virtual machine) needs to run a bunch
 of processes as root. Those typically include SSH, cron, syslogd;
-hardware management tools (to e.g. load modules), network configuration
-tools (to handle e.g. DHCP, WPA, or VPNs), and much more. A container is
+hardware management tools (e.g., load modules), network configuration
+tools (e.g., to handle DHCP, WPA, or VPNs), and much more. A container is
 very different, because almost all of those tasks are handled by the
 infrastructure around the container:
 
@@ -199,15 +194,18 @@ container, it will be much harder to do serious damage, or to escalate
 to the host.
 
 This won't affect regular web apps; but malicious users will find that
-the arsenal at their disposal has shrunk considerably! You can see [the
-list of dropped capabilities in the Docker
-code](https://github.com/dotcloud/docker/blob/v0.5.0/lxc_template.go#L97),
-and a full list of available capabilities in [Linux
+the arsenal at their disposal has shrunk considerably! By default Docker
+drops all capabilities except [those
+needed](https://github.com/dotcloud/docker/blob/master/daemon/execdriver/native/template/default_template.go),
+a whitelist instead of a blacklist approach. You can see a full list of
+available capabilities in [Linux
 manpages](http://man7.org/linux/man-pages/man7/capabilities.7.html).
 
 Of course, you can always enable extra capabilities if you really need
 them (for instance, if you want to use a FUSE-based filesystem), but by
-default, Docker containers will be locked down to ensure maximum safety.
+default, Docker containers use only a
+[whitelist](https://github.com/dotcloud/docker/blob/master/daemon/execdriver/native/template/default_template.go)
+of kernel capabilities by default.
 
 ## Other Kernel Security Features
 
@@ -222,20 +220,19 @@ harden a Docker host. Here are a few examples.
 
  - You can run a kernel with GRSEC and PAX. This will add many safety
    checks, both at compile-time and run-time; it will also defeat many
-   exploits, thanks to techniques like address randomization. It
-   doesn't require Docker-specific configuration, since those security
-   features apply system-wide, independently of containers.
- - If your distribution comes with security model templates for LXC
-   containers, you can use them out of the box. For instance, Ubuntu
-   comes with AppArmor templates for LXC, and those templates provide
-   an extra safety net (even though it overlaps greatly with
-   capabilities).
+   exploits, thanks to techniques like address randomization. It doesn't
+   require Docker-specific configuration, since those security features
+   apply system-wide, independently of containers.
+ - If your distribution comes with security model templates for
+   Docker containers, you can use them out of the box. For instance, we
+   ship a template that works with AppArmor and Red Hat comes with SELinux
+   policies for Docker. These templates provide an extra safety net (even
+   though it overlaps greatly with capabilities).
  - You can define your own policies using your favorite access control
-   mechanism. Since Docker containers are standard LXC containers,
-   there is nothing “magic” or specific to Docker.
+   mechanism.
 
 Just like there are many third-party tools to augment Docker containers
-with e.g. special network topologies or shared filesystems, you can
+with e.g., special network topologies or shared filesystems, you can
 expect to see tools to harden existing Docker containers without
 affecting Docker's core.
 
@@ -243,7 +240,7 @@ affecting Docker's core.
 
 Docker containers are, by default, quite secure; especially if you take
 care of running your processes inside the containers as non-privileged
-users (i.e. non root).
+users (i.e. non-`root`).
 
 You can add an extra layer of safety by enabling Apparmor, SELinux,
 GRSEC, or your favorite hardening solution.
@@ -254,4 +251,4 @@ with Docker, since everything is provided by the kernel anyway.
 
 For more context and especially for comparisons with VMs and other
 container systems, please also see the [original blog post](
-http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/).
+http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/).
diff --git a/docs/sources/articles/using_supervisord.md b/docs/sources/articles/using_supervisord.md
index fd7c07cabf..91b8976d78 100644
--- a/docs/sources/articles/using_supervisord.md
+++ b/docs/sources/articles/using_supervisord.md
@@ -27,7 +27,7 @@ Let's start by creating a basic `Dockerfile` for our
 new image.
 
     FROM ubuntu:13.04
-    MAINTAINER examples@docker.io
+    MAINTAINER examples@docker.com
     RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list
     RUN apt-get update
     RUN apt-get upgrade -y