Merge pull request #15701 from moxiegirl/819-publish-cherrypicks

819 publish cherrypicks
Update volumes userguide
2026-08-23 15:37:26 +00:00 · 2015-08-19 13:41:37 -07:00 · 2015-08-19 10:07:50 -07:00 · 2015-08-19 10:07:39 -07:00 · 2015-08-19 10:06:47 -07:00 · 2015-08-19 10:06:38 -07:00
101 changed files with 2846 additions and 4194 deletions
@@ -1,11 +1,5 @@
 # Changelog
 ## 1.8.1 (2015-08-12)
 ### Distribution
 - Fix a bug where pushing multiple tags would result in invalid images
 ## 1.8.0 (2015-08-11)
 ### Distribution
@@ -1 +1 @@
-1.8.1-clear-containers
+1.8.0
@@ -11,7 +11,7 @@ import (
 var (
 	defaultPidFile = "/var/run/docker.pid"
 	defaultGraph   = "/var/lib/docker"
-	defaultExec    = "clr"
+	defaultExec    = "native"
 )
 // Config defines the configuration of a docker daemon.
@@ -1,721 +0,0 @@
 // +build linux
 package clr
 import (
 	"fmt"
 	"io"
 	"io/ioutil"
 	"math"
 	"net/http"
 	"os"
 	"os/exec"
 	"net"
 	"path"
 	"strconv"
 	"strings"
 	"sync"
 	"syscall"
 	"github.com/Sirupsen/logrus"
 	"github.com/docker/docker/daemon/execdriver"
 	"github.com/docker/docker/pkg/mount"
 	sysinfo "github.com/docker/docker/pkg/system"
 	"github.com/docker/docker/pkg/term"
 	"github.com/docker/libnetwork/netlabel"
 	"github.com/kr/pty"
 	"github.com/opencontainers/runc/libcontainer/configs"
 )
 const (
 	// Clear Linux for Intel(R) Architecture
 	driverName = "clr"
 	envVarPrefix = "CLR_"
 	// Command used for lkvm control
 	lkvmName = "lkvm"
 	// local "latest" information
 	clrFile = "latest"
 	// upstream base URL
 	clrURL = "https://download.clearlinux.org"
 	// upstream latest release file
 	latestFile = "https://download.clearlinux.org/latest"
 	// clr kernel (not bzimage)
 	clrKernel = "/usr/lib/kernel/vmlinux.container"
 )
 type driver struct {
 	root             string // root path for the driver to use
 	libPath          string
 	initPath         string
 	version          string
 	apparmor         bool
 	sharedRoot       bool
 	activeContainers map[string]*activeContainer
 	machineMemory    int64
 	containerPid     int
 	sync.Mutex
 }
 type activeContainer struct {
 	container *configs.Config
 	cmd       *exec.Cmd
 }
 func getTapIf(c *execdriver.Command) string {
 	return fmt.Sprintf("tb-%s", c.ID[:12])
 }
 func getClrVersion(libPath string) string {
 	txt, err := ioutil.ReadFile(path.Join(libPath, clrFile))
 	if err != nil {
 		return ""
 	}
 	return strings.Split(string(txt), "\n")[0]
 }
 func fetchLatest(libPath string) error {
 	out, err := os.Create(path.Join(libPath, clrFile))
 	if err != nil {
 		return err
 	}
 	defer out.Close()
 	resp, err := http.Get(latestFile)
 	if err != nil {
 		return err
 	}
 	defer resp.Body.Close()
 	_, err = io.Copy(out, resp.Body)
 	return err
 }
 func fetchImage(version, libPath string) error {
 	// TODO: Add checksum validation
 	outfile := fmt.Sprintf("clear-%s-containers.img.xz", version)
 	url := fmt.Sprintf("%s/releases/%s/clear/%s", clrURL, version, outfile)
 	outpath := path.Join(libPath, outfile)
 	var output []byte
 	logrus.Debugf("Fetching clr version: %s, %s", version, outpath)
 	out, err := os.Create(outpath)
 	if err != nil {
 		return err
 	}
 	defer out.Close()
 	resp, err := http.Get(url)
 	if err != nil {
 		return err
 	}
 	defer resp.Body.Close()
 	// Consider progress feedback ?
 	_, err = io.Copy(out, resp.Body)
 	if err != nil {
 		return err
 	}
 	// decompress the file
 	cmd := exec.Command("unxz", outpath)
 	cmd.Dir = libPath
 	if output, err = cmd.CombinedOutput(); err != nil {
 		logrus.Debugf("Unable to extract image %s: %s", version, output)
 		return err
 	}
 	return nil
 }
 // NewDriver creates a new clear linux execution driver.
 func NewDriver(root, libPath, initPath string, apparmor bool) (*driver, error) {
 	if err := os.MkdirAll(root, 0700); err != nil {
 		return nil, err
 	}
 	meminfo, err := sysinfo.ReadMemInfo()
 	if err != nil {
 		return nil, err
 	}
 	version, err := prepareClr(libPath)
 	if err != nil {
 		return nil, err
 	}
 	return &driver{
 		apparmor:         apparmor,
 		root:             root,
 		libPath:          libPath,
 		initPath:         initPath,
 		version:          version,
 		sharedRoot:       false,
 		activeContainers: make(map[string]*activeContainer),
 		// FIXME:
 		machineMemory: meminfo.MemTotal,
 	}, nil
 }
 func prepareClr(libPath string) (string, error) {
 	var version = getClrVersion(libPath)
 	var nversion string
 	logrus.Debugf("%s preparing environment", driverName)
 	err := fetchLatest(libPath)
 	if err != nil {
 		return "", err
 	}
 	nversion = getClrVersion(libPath)
 	if nversion != version && version != "" {
 		logrus.Debugf("Updating to clr version: %s", nversion)
 		err = fetchImage(nversion, libPath)
 	} else if version == "" {
 		logrus.Debugf("Installing clr version: %s", nversion)
 		err = fetchImage(nversion, libPath)
 	} else {
 		logrus.Debugf("Using clr version: %s", nversion)
 	}
 	return nversion, nil
 }
 func (d *driver) Name() string {
 	return fmt.Sprintf("%s-%s", driverName, d.version)
 }
 func (d *driver) Run(c *execdriver.Command, pipes *execdriver.Pipes, startCallback execdriver.StartCallback) (execdriver.ExitStatus, error) {
 	var (
 		term execdriver.Terminal
 		err  error
 	)
 	container, err := d.createContainer(c)
 	if err != nil {
 		return execdriver.ExitStatus{ExitCode: -1}, err
 	}
 	memoryMiB := c.HostConfig.Memory
 	if memoryMiB == 0 {
 		memoryMiB = 1024
 	} else {
 		// docker passes the value as bytes
 		memoryMiB = memoryMiB / int64(math.Pow(2, 20))
 	}
 	workingDirVar := fmt.Sprintf("%s%s=%q", envVarPrefix, "WORKINGDIR", c.WorkingDir)
 	c.ProcessConfig.Cmd.Env = append(c.ProcessConfig.Cmd.Env, workingDirVar)
 	userVar := fmt.Sprintf("%s%s=%q", envVarPrefix, "USER", c.ProcessConfig.User)
 	c.ProcessConfig.Cmd.Env = append(c.ProcessConfig.Cmd.Env, userVar)
 	if err := d.setupNetwork(c); err != nil {
 		return execdriver.ExitStatus{ExitCode: -1}, err
 	}
 	if c.ProcessConfig.Tty {
 		term, err = NewTtyConsole(&c.ProcessConfig, pipes)
 	} else {
 		term, err = execdriver.NewStdConsole(&c.ProcessConfig, pipes)
 	}
 	if err != nil {
 		return execdriver.ExitStatus{ExitCode: -1}, err
 	}
 	c.ProcessConfig.Terminal = term
 	d.Lock()
 	d.activeContainers[c.ID] = &activeContainer{
 		container: container,
 		cmd:       &c.ProcessConfig.Cmd,
 	}
 	d.Unlock()
 	if err := d.generateEnvConfig(c); err != nil {
 		return execdriver.ExitStatus{ExitCode: -1}, err
 	}
 	if err := d.generateDockerInit(c); err != nil {
 		return execdriver.ExitStatus{ExitCode: -1}, err
 	}
 	for _, m := range c.Mounts {
 		dest := path.Join(c.Rootfs, m.Destination)
 		if m.Destination == "/etc/hostname" {
 			continue
 		}
 		if !pathExists(m.Source) {
 			continue
 		}
 		opts := "bind"
 		if m.Private {
 			opts = opts + ",rprivate"
 		}
 		if m.Slave {
 			opts = opts + ",rslave"
 		}
 		// This may look racy, but it isn't since the VM isn't
 		// running yet.
 		//
 		// The check is necessary to handle bind mounting of
 		// regular files correctly since without it we may be
 		// attempting to create a directory where there already
 		// exists a normal file.
 		if !pathExists(dest) {
 			if err := os.MkdirAll(dest, 0750); err != nil {
 				return execdriver.ExitStatus{ExitCode: -1}, err
 			}
 		}
 		if err := mount.Mount(m.Source, dest, "", opts); err != nil {
 			return execdriver.ExitStatus{ExitCode: -1}, err
 		}
 		if !m.Writable {
 			if err := mount.Mount("", dest, "", "bind,remount,ro"); err != nil {
 				return execdriver.ExitStatus{ExitCode: -1}, err
 			}
 		}
 		defer mount.Unmount(dest)
 	}
 	var args []string
 	// various things for lkvm
 	ifname := getTapIf(c)
 	// FIXME: Should be real hostname from like process/container struct
 	hostname := c.ID[0:12]
 	img := fmt.Sprintf("%s/clear-%s-containers.img", d.libPath, d.version)
 	memory := fmt.Sprintf("%d", memoryMiB)
 	// FIXME: Locked cores to 6 ?
 	cores := fmt.Sprintf("%d", 6)
 	ipaddr := c.NetworkSettings.IPAddress
 	gateway := c.NetworkSettings.Gateway
 	macaddr := c.NetworkSettings.MacAddress
 	args = append(args, c.ProcessConfig.Entrypoint)
 	args = append(args, c.ProcessConfig.Arguments...)
 	rootParams := fmt.Sprintf("root=/dev/plkvm0p1 rootfstype=ext4 rootflags=dax,data=ordered "+
 		"init=/usr/lib/systemd/systemd systemd.unit=container.target rw tsc=reliable "+
 		"systemd.show_status=false "+
 		"no_timer_check rcupdate.rcu_expedited=1 console=hvc0 quiet ip=%s::%s::%s::off",
 		ipaddr, gateway, hostname)
 	params := []string{
 		lkvmName, "run", "-c", cores, "-m", memory,
 		"--name", c.ID, "--console", "virtio",
 		"--kernel", clrKernel,
 		"--params", rootParams,
 		"--shmem", fmt.Sprintf("0x200000000:0:file=%s:private", img),
 		"--network", fmt.Sprintf("mode=tap,script=none,tapif=%s,guest_mac=%s", ifname, macaddr),
 		"--9p", fmt.Sprintf("%s,rootfs", c.Rootfs),
 	}
 	logrus.Debugf("%s params %s", driverName, params)
 	var (
 		name = params[0]
 		arg  = params[1:]
 	)
 	aname, err := exec.LookPath(name)
 	if err != nil {
 		aname = name
 	}
 	c.ProcessConfig.Path = aname
 	c.ProcessConfig.Args = append([]string{name}, arg...)
 	c.ProcessConfig.Env = []string{fmt.Sprintf("HOME=%s", d.root)}
 	// Start the container. Since it runs synchronously, we don't Wait()
 	// for it since we need to check the status to determine if it did
 	// actually start successfully.
 	if err := c.ProcessConfig.Start(); err != nil {
 		return execdriver.ExitStatus{ExitCode: -1}, err
 	}
 	var (
 		waitErr  error
 		waitLock = make(chan struct{})
 	)
 	go func() {
 		if err := c.ProcessConfig.Wait(); err != nil {
 			if _, ok := err.(*exec.ExitError); !ok { // Do not propagate the error if it's simply a status code != 0
 				waitErr = err
 			}
 		}
 		close(waitLock)
 	}()
 	// FIXME: need to create state.json for Stats() to work.
 	c.ContainerPid = c.ProcessConfig.Process.Pid
 	d.containerPid = c.ProcessConfig.Process.Pid
 	if startCallback != nil {
 		logrus.Debugf("Invoking startCallback")
 		startCallback(&c.ProcessConfig, c.ProcessConfig.Process.Pid)
 	}
 	// FIXME:
 	oomKill := false
 	// Wait for the VM to shutdown
 	<-waitLock
 	exitCode := getExitCode(c)
 	cExitStatus, cerr := d.cleanupVM(c)
 	if cerr != nil {
 		waitErr = cerr
 		exitCode = cExitStatus
 	}
 	// check oom error
 	if oomKill {
 		exitCode = 137
 	}
 	return execdriver.ExitStatus{ExitCode: exitCode, OOMKilled: false}, waitErr
 }
 func pathExists(path string) bool {
 	if _, err := os.Stat(path); err == nil {
 		return true
 	}
 	return false
 }
 func pathExecutable(path string) bool {
 	s, err := os.Stat(path)
 	if err != nil {
 		return false
 	}
 	mode := s.Mode()
 	if mode&0111 != 0 {
 		return true
 	}
 	return false
 }
 func (d *driver) cleanupVM(c *execdriver.Command) (exitStatus int, err error) {
 	cmd := exec.Command("ip", "tuntap", "del", "dev", getTapIf(c), "mode", "tap")
 	var output []byte
 	if output, err = cmd.CombinedOutput(); err != nil {
 		if exitError, ok := err.(*exec.ExitError); ok {
 			waitStatus := exitError.Sys().(syscall.WaitStatus)
 			exitStatus = waitStatus.ExitStatus()
 		}
 		logrus.Debugf("teardown failed for vm %s: %s (%s)", c.ID, string(output), err.Error())
 	}
 	// doesn't matter if this fails
 	// lkvm could have removed it, and stale sockets are not fatal
 	_ = os.Remove(fmt.Sprintf("%s/.lkvm/%s.sock", d.root, c.ID))
 	return exitStatus, err
 }
 // createContainer populates and configures the container type with the
 // data provided by the execdriver.Command
 func (d *driver) createContainer(c *execdriver.Command) (*configs.Config, error) {
 	return execdriver.InitContainer(c), nil
 }
 /// Return the exit code of the process
 // if the process has not exited -1 will be returned
 func getExitCode(c *execdriver.Command) int {
 	if c.ProcessConfig.ProcessState == nil {
 		return -1
 	}
 	return c.ProcessConfig.ProcessState.Sys().(syscall.WaitStatus).ExitStatus()
 }
 func (d *driver) lkvmCommand(c *execdriver.Command, arg string) ([]byte, error) {
 	args := append([]string{lkvmName}, arg)
 	if c != nil {
 		args = append(args, "--name", c.ID)
 	}
 	cmd := exec.Command(lkvmName, args...)
 	cmd.Env = []string{fmt.Sprintf("HOME=%s", d.root)}
 	return cmd.Output()
 }
 // Kill sends a signal to workload
 func (d *driver) Kill(c *execdriver.Command, sig int) error {
 	// Not supported
 	return nil
 }
 func (d *driver) Pause(c *execdriver.Command) error {
 	_, err := d.lkvmCommand(c, "pause")
 	return err
 }
 func (d *driver) Unpause(c *execdriver.Command) error {
 	_, err := d.lkvmCommand(c, "resume")
 	return err
 }
 // Terminate forcibly stops a container
 func (d *driver) Terminate(c *execdriver.Command) error {
 	_, err := d.lkvmCommand(c, "stop")
 	return err
 }
 func (d *driver) containerDir(containerID string) string {
 	return path.Join(d.libPath, "containers", containerID)
 }
 // isDigit returns true if s can be represented as an integer
 func isDigit(s string) bool {
 	if _, err := strconv.Atoi(s); err == nil {
 		return true
 	}
 	return false
 }
 func (d *driver) getInfo(id string) ([]byte, error) {
 	output, err := d.lkvmCommand(nil, "list")
 	if err != nil {
 		return nil, err
 	}
 	for i, line := range strings.Split(string(output), "\n") {
 		if i < 2 {
 			continue
 		}
 		fields := strings.Fields(strings.TrimSpace(line))
 		if len(fields) != 3 {
 			continue
 		}
 		if !isDigit(fields[0]) {
 			continue
 		}
 		if fields[1] != id {
 			continue
 		}
 		return []byte(line), nil
 	}
 	return []byte(fmt.Sprintf("-1 %s stopped", id)), nil
 }
 type info struct {
 	ID     string
 	driver *driver
 }
 func (i *info) IsRunning() bool {
 	output, err := i.driver.getInfo(i.ID)
 	if err != nil {
 		logrus.Errorf("Error getting info for %s container %s: %s (%s)",
 			driverName, i.ID, err, output)
 		return false
 	}
 	clrInfo, err := parseClrInfo(i.ID, string(output))
 	if err != nil {
 		return false
 	}
 	return clrInfo.Running
 }
 func (d *driver) Info(id string) execdriver.Info {
 	return &info{
 		ID:     id,
 		driver: d,
 	}
 }
 func (d *driver) GetPidsForContainer(id string) ([]int, error) {
 	// The VM doesn't expose the worload pid(s), so the only meaningful
 	// pid is that of the VM
 	return []int{d.containerPid}, nil
 }
 // TtyConsole is a type to represent a pseud-oterminal (see pty(7))
 type TtyConsole struct {
 	MasterPty *os.File
 	SlavePty  *os.File
 }
 // NewTtyConsole returns a new TtyConsole object.
 func NewTtyConsole(processConfig *execdriver.ProcessConfig, pipes *execdriver.Pipes) (*TtyConsole, error) {
 	// lxc is special in that we cannot create the master outside of the container without
 	// opening the slave because we have nothing to provide to the cmd.  We have to open both then do
 	// the crazy setup on command right now instead of passing the console path to lxc and telling it
 	// to open up that console.  we save a couple of openfiles in the native driver because we can do
 	// this.
 	ptyMaster, ptySlave, err := pty.Open()
 	if err != nil {
 		return nil, err
 	}
 	tty := &TtyConsole{
 		MasterPty: ptyMaster,
 		SlavePty:  ptySlave,
 	}
 	if err := tty.AttachPipes(&processConfig.Cmd, pipes); err != nil {
 		tty.Close()
 		return nil, err
 	}
 	processConfig.Console = tty.SlavePty.Name()
 	return tty, nil
 }
 // Master returns the master end of the pty
 func (t *TtyConsole) Master() *os.File {
 	return t.MasterPty
 }
 // Resize modifies the size of the pty terminal being used.
 func (t *TtyConsole) Resize(h, w int) error {
 	return term.SetWinsize(t.MasterPty.Fd(), &term.Winsize{Height: uint16(h), Width: uint16(w)})
 }
 // AttachPipes associates the specified pipes with the pty master.
 func (t *TtyConsole) AttachPipes(command *exec.Cmd, pipes *execdriver.Pipes) error {
 	command.Stdout = t.SlavePty
 	command.Stderr = t.SlavePty
 	go func() {
 		if wb, ok := pipes.Stdout.(interface {
 			CloseWriters() error
 		}); ok {
 			defer wb.CloseWriters()
 		}
 		io.Copy(pipes.Stdout, t.MasterPty)
 	}()
 	if pipes.Stdin != nil {
 		command.Stdin = t.SlavePty
 		command.SysProcAttr.Setctty = true
 		go func() {
 			io.Copy(t.MasterPty, pipes.Stdin)
 			pipes.Stdin.Close()
 		}()
 	}
 	return nil
 }
 // Close closes both ends of the pty.
 func (t *TtyConsole) Close() error {
 	t.SlavePty.Close()
 	return t.MasterPty.Close()
 }
 func (d *driver) Exec(c *execdriver.Command, processConfig *execdriver.ProcessConfig, pipes *execdriver.Pipes, startCallback execdriver.StartCallback) (int, error) {
 	return -1, fmt.Errorf("Unsupported: Exec is not supported by the %q driver", driverName)
 }
 // Clean up after an Exec
 func (d *driver) Clean(id string) error {
 	return nil
 }
 func (d *driver) generateEnvConfig(c *execdriver.Command) error {
 	data := []byte(strings.Join(c.ProcessConfig.Env, "\n"))
 	p := path.Join(d.libPath, "containers", c.ID, "config.env")
 	c.Mounts = append(c.Mounts, execdriver.Mount{
 		Source:      p,
 		Destination: "/.dockerenv",
 		Writable:    false,
 		Private:     true,
 	})
 	return ioutil.WriteFile(p, data, 0600)
 }
 func (d *driver) generateDockerInit(c *execdriver.Command) error {
 	p := fmt.Sprintf("%s/.containerexec", c.Rootfs)
 	var args []string
 	if pathExecutable(p) {
 		return nil
 	}
 	args = append(args, c.ProcessConfig.Entrypoint)
 	args = append(args, c.ProcessConfig.Arguments...)
 	data := []byte(fmt.Sprintf("#!/bin/sh\n%s\n", strings.Join(args, " ")))
 	return ioutil.WriteFile(p, data, 0755)
 }
 func (d *driver) setupNetwork(c *execdriver.Command) error {
 	ifname := getTapIf(c)
 	var bridgeName string
 	var bridgeLinkName string
 	var output []byte
 	var err error
 	for _, info := range c.EndpointInfo {
 		if mac, ok := info[netlabel.MacAddress].(net.HardwareAddr); ok {
 			if mac.String() == c.NetworkSettings.MacAddress {
 				bridgeName = info[netlabel.BridgeName].(string)
 				bridgeLinkName = info[netlabel.BridgeLinkName].(string)
 			}
 		}
 	}
 	// Strip existing veth
 	cmd := exec.Command("ip", "link", "del", bridgeLinkName)
 	if output, err = cmd.CombinedOutput(); err != nil {
 		logrus.Debugf("%s setupNetwork error: %v, %s", driverName, cmd.Args, output)
 		return err
 	}
 	cmd = exec.Command("ip", "tuntap", "add", "dev", ifname, "mode", "tap", "vnet_hdr")
 	if output, err = cmd.CombinedOutput(); err != nil {
 		logrus.Debugf("%s setupNetwork error: %v, %s", driverName, cmd.Args, output)
 		return err
 	}
 	cmd = exec.Command("ip", "link", "set", "dev", ifname, "master", bridgeName)
 	if output, err = cmd.CombinedOutput(); err != nil {
 		logrus.Debugf("%s setupNetwork error: %v, %s", driverName, cmd.Args, output)
 		return err
 	}
 	cmd = exec.Command("ip", "link", "set", "dev", ifname, "up")
 	if output, err = cmd.CombinedOutput(); err != nil {
 		logrus.Debugf("%s setupNetwork error: %v, %s", driverName, cmd.Args, output)
 		return err
 	}
 	return err
 }
 func (d *driver) Stats(id string) (*execdriver.ResourceStats, error) {
 	if _, ok := d.activeContainers[id]; !ok {
 		return nil, fmt.Errorf("%s is not a key in active containers", id)
 	}
 	// FIXME:
 	return execdriver.Stats(d.containerDir(id), d.activeContainers[id].container.Cgroups.Memory, d.machineMemory)
 }
@@ -1,51 +0,0 @@
 // +build linux
 package clr
 import (
 	"errors"
 	"strconv"
 	"strings"
 )
 var (
 	ErrCannotParse = errors.New("cannot parse raw input")
 )
 type clrInfo struct {
 	Running bool
 	Pid     int
 }
 func parseClrInfo(name, raw string) (*clrInfo, error) {
 	if raw == "" {
 		return nil, ErrCannotParse
 	}
 	var (
 		err  error
 		info = &clrInfo{}
 	)
 	fields := strings.Fields(strings.TrimSpace(raw))
 	// The format is expected to be:
 	//
 	// <pid> <name> <state>
 	//
 	if len(fields) != 3 {
 		return nil, ErrCannotParse
 	}
 	info.Pid, err = strconv.Atoi(fields[0])
 	if err != nil {
 		return nil, ErrCannotParse
 	}
 	if fields[1] != name {
 		return nil, ErrCannotParse
 	}
 	info.Running = fields[2] == "running"
 	return info, nil
 }
@@ -1,97 +0,0 @@
 // +build linux
 package clr
 import (
 	"encoding/json"
 	"flag"
 	"fmt"
 	"os"
 	"strings"
 	"syscall"
 )
 // Args provided to the init function for a driver
 type InitArgs struct {
 	User       string
 	Gateway    string
 	Ip         string
 	WorkDir    string
 	Privileged bool
 	Env        []string
 	Args       []string
 	Mtu        int
 	Console    string
 	Pipe       int
 	Root       string
 	CapAdd     string
 	CapDrop    string
 }
 func getArgs() *InitArgs {
 	var (
 		// Get cmdline arguments
 		user       = flag.String("u", "", "username or uid")
 		gateway    = flag.String("g", "", "gateway address")
 		ip         = flag.String("i", "", "ip address")
 		workDir    = flag.String("w", "", "workdir")
 		privileged = flag.Bool("privileged", false, "privileged mode")
 		mtu        = flag.Int("mtu", 1500, "interface mtu")
 		capAdd     = flag.String("cap-add", "", "capabilities to add")
 		capDrop    = flag.String("cap-drop", "", "capabilities to drop")
 	)
 	flag.Parse()
 	return &InitArgs{
 		User:       *user,
 		Gateway:    *gateway,
 		Ip:         *ip,
 		WorkDir:    *workDir,
 		Privileged: *privileged,
 		Args:       flag.Args(),
 		Mtu:        *mtu,
 		CapAdd:     *capAdd,
 		CapDrop:    *capDrop,
 	}
 }
 // Clear environment pollution introduced by lxc-start
 func setupEnv(args *InitArgs) error {
 	// Get env
 	var env []string
 	dockerenv, err := os.Open(".dockerenv")
 	if err != nil {
 		return fmt.Errorf("Unable to load environment variables: %v", err)
 	}
 	defer dockerenv.Close()
 	if err := json.NewDecoder(dockerenv).Decode(&env); err != nil {
 		return fmt.Errorf("Unable to decode environment variables: %v", err)
 	}
 	// Propagate the plugin-specific container env variable
 	env = append(env, "container="+os.Getenv("container"))
 	args.Env = env
 	os.Clearenv()
 	for _, kv := range args.Env {
 		parts := strings.SplitN(kv, "=", 2)
 		if len(parts) == 1 {
 			parts = append(parts, "")
 		}
 		os.Setenv(parts[0], parts[1])
 	}
 	return nil
 }
 // Setup working directory
 func setupWorkingDirectory(args *InitArgs) error {
 	if args.WorkDir == "" {
 		return nil
 	}
 	if err := syscall.Chdir(args.WorkDir); err != nil {
 		return fmt.Errorf("Unable to change dir to %v: %v", args.WorkDir, err)
 	}
 	return nil
 }
@@ -7,9 +7,7 @@ import (
 	"time"
 	// TODO Windows: Factor out ulimit
 	"github.com/docker/docker/daemon/network"
 	"github.com/docker/docker/pkg/ulimit"
 	"github.com/docker/docker/runconfig"
 	"github.com/opencontainers/runc/libcontainer"
 	"github.com/opencontainers/runc/libcontainer/configs"
 )
@@ -152,34 +150,31 @@ type ProcessConfig struct {
 //
 // Process wrapps an os/exec.Cmd to add more metadata
 type Command struct {
-	ID                 string                   `json:"id"`
+	ID                 string            `json:"id"`
-	Rootfs             string                   `json:"rootfs"` // root fs of the container
+	Rootfs             string            `json:"rootfs"` // root fs of the container
-	ReadonlyRootfs     bool                     `json:"readonly_rootfs"`
+	ReadonlyRootfs     bool              `json:"readonly_rootfs"`
-	InitPath           string                   `json:"initpath"` // dockerinit
+	InitPath           string            `json:"initpath"` // dockerinit
-	WorkingDir         string                   `json:"working_dir"`
+	WorkingDir         string            `json:"working_dir"`
-	ConfigPath         string                   `json:"config_path"` // this should be able to be removed when the lxc template is moved into the driver
+	ConfigPath         string            `json:"config_path"` // this should be able to be removed when the lxc template is moved into the driver
-	Network            *Network                 `json:"network"`
+	Network            *Network          `json:"network"`
-	Ipc                *Ipc                     `json:"ipc"`
+	Ipc                *Ipc              `json:"ipc"`
-	Pid                *Pid                     `json:"pid"`
+	Pid                *Pid              `json:"pid"`
-	UTS                *UTS                     `json:"uts"`
+	UTS                *UTS              `json:"uts"`
-	Resources          *Resources               `json:"resources"`
+	Resources          *Resources        `json:"resources"`
-	Mounts             []Mount                  `json:"mounts"`
+	Mounts             []Mount           `json:"mounts"`
-	AllowedDevices     []*configs.Device        `json:"allowed_devices"`
+	AllowedDevices     []*configs.Device `json:"allowed_devices"`
-	AutoCreatedDevices []*configs.Device        `json:"autocreated_devices"`
+	AutoCreatedDevices []*configs.Device `json:"autocreated_devices"`
-	CapAdd             []string                 `json:"cap_add"`
+	CapAdd             []string          `json:"cap_add"`
-	CapDrop            []string                 `json:"cap_drop"`
+	CapDrop            []string          `json:"cap_drop"`
-	GroupAdd           []string                 `json:"group_add"`
+	GroupAdd           []string          `json:"group_add"`
-	ContainerPid       int                      `json:"container_pid"`  // the pid for the process inside a container
+	ContainerPid       int               `json:"container_pid"`  // the pid for the process inside a container
-	ProcessConfig      ProcessConfig            `json:"process_config"` // Describes the init process of the container.
+	ProcessConfig      ProcessConfig     `json:"process_config"` // Describes the init process of the container.
-	ProcessLabel       string                   `json:"process_label"`
+	ProcessLabel       string            `json:"process_label"`
-	MountLabel         string                   `json:"mount_label"`
+	MountLabel         string            `json:"mount_label"`
-	LxcConfig          []string                 `json:"lxc_config"`
+	LxcConfig          []string          `json:"lxc_config"`
-	AppArmorProfile    string                   `json:"apparmor_profile"`
+	AppArmorProfile    string            `json:"apparmor_profile"`
-	CgroupParent       string                   `json:"cgroup_parent"` // The parent cgroup for this command.
+	CgroupParent       string            `json:"cgroup_parent"` // The parent cgroup for this command.
-	FirstStart         bool                     `json:"first_start"`
+	FirstStart         bool              `json:"first_start"`
-	LayerPaths         []string                 `json:"layer_paths"` // Windows needs to know the layer paths and folder for a command
+	LayerPaths         []string          `json:"layer_paths"` // Windows needs to know the layer paths and folder for a command
-	LayerFolder        string                   `json:"layer_folder"`
+	LayerFolder        string            `json:"layer_folder"`
 	NetworkSettings    *network.Settings        `json:"network_settings"`
 	EndpointInfo       []map[string]interface{} `json:"endpoint_info"`
 	HostConfig         *runconfig.HostConfig
 }
@@ -8,17 +8,13 @@ import (
 	"github.com/Sirupsen/logrus"
 	"github.com/docker/docker/daemon/execdriver"
 	"github.com/docker/docker/daemon/execdriver/clr"
 	"github.com/docker/docker/daemon/execdriver/lxc"
 	"github.com/docker/docker/daemon/execdriver/native"
 	"github.com/docker/docker/pkg/sysinfo"
 )
 func NewDriver(name string, options []string, root, libPath, initPath string, sysInfo *sysinfo.SysInfo) (execdriver.Driver, error) {
 	rootPath := path.Join(root, "execdriver", name)
 	switch name {
 	case "clr":
 		return clr.NewDriver(rootPath, libPath, initPath, sysInfo.AppArmor)
 	case "lxc":
 		// we want to give the lxc driver the full docker root because it needs
 		// to access and write config and template files in /var/lib/docker/containers/*
@@ -26,7 +22,7 @@ func NewDriver(name string, options []string, root, libPath, initPath string, sy
 		logrus.Warn("LXC built-in support is deprecated.")
 		return lxc.NewDriver(root, libPath, initPath, sysInfo.AppArmor)
 	case "native":
-		return native.NewDriver(rootPath, initPath, options)
+		return native.NewDriver(path.Join(root, "execdriver", "native"), initPath, options)
 	}
 	return nil, fmt.Errorf("unknown exec driver %s", name)
 }
@@ -1482,16 +1482,12 @@ func (devices *DeviceSet) deactivatePool() error {
 	if err != nil {
 		return err
 	}
 	if devinfo.Exists == 0 {
 		return nil
 	}
 	if err := devicemapper.RemoveDevice(devname); err != nil {
 		return err
 	}
 	if d, err := devicemapper.GetDeps(devname); err == nil {
-		logrus.Warnf("[devmapper] device %s still has %d active dependents", devname, d.Count)
+		// Access to more Debug output
 		logrus.Debugf("[devmapper] devicemapper.GetDeps() %s: %#v", devname, d)
 	}
 	if devinfo.Exists != 0 {
 		return devicemapper.RemoveDevice(devname)
 	}
 	return nil
@@ -138,30 +138,6 @@ func (m *containerMonitor) Start() error {
 		m.lastStartTime = time.Now()
 		// Make the network settings available to the execution
 		// driver to allow for integration with libnetwork networking.
 		m.container.command.NetworkSettings = m.container.NetworkSettings
 		// Allow the execution driver to query memory limits
 		m.container.command.HostConfig = m.container.hostConfig
 		// Make the network endpoint details available to the execution
 		// driver as well.
 		n, _err := m.container.daemon.netController.NetworkByID(m.container.NetworkSettings.NetworkID)
 		if _err == nil {
 			var eps []map[string]interface{}
 			for _, ep := range n.Endpoints() {
 				info, err := ep.DriverInfo()
 				if err != nil {
 					continue
 				}
 				eps = append(eps, info)
 			}
 			m.container.command.EndpointInfo = eps
 		}
 		if exitStatus, err = m.container.daemon.Run(m.container, pipes, m.callback); err != nil {
 			// if we receive an internal error from the initial start of a container then lets
 			// return it instead of entering the restart loop
@@ -6,8 +6,24 @@ COPY . /src
 COPY . /docs/content/
-WORKDIR /docs/content
+RUN svn checkout https://github.com/docker/compose/trunk/docs /docs/content/compose
 RUN svn checkout https://github.com/docker/swarm/trunk/docs /docs/content/swarm
 RUN svn checkout https://github.com/docker/machine/trunk/docs /docs/content/machine
 RUN svn checkout https://github.com/docker/distribution/trunk/docs /docs/content/registry
 RUN svn checkout https://github.com/kitematic/kitematic/trunk/docs /docs/content/kitematic
 RUN svn checkout https://github.com/docker/tutorials/trunk/docs /docs/content/
 RUN svn checkout https://github.com/docker/opensource/trunk/docs /docs/content/opensource
 RUN /docs/content/touch-up.sh
-WORKDIR /docs
+
 # Sed to process GitHub Markdown
 # 1-2 Remove comment code from metadata block
 # 3 Change ](/word to ](/project/ in links
 # 4 Change ](word.md) to ](/project/word)
 # 5 Remove .md extension from link text
 # 6 Change ](../ to ](/project/word) 
 # 7 Change ](../../ to ](/project/ --> not implemented
 # 
 # 
 RUN /src/pre-process.sh /docs
@@ -11,7 +11,7 @@ parent = "smn_images"
 # Create a base image
 So you want to create your own [*Base Image*](
-/terms/image/#base-image)? Great!
+/reference/glossary/#base-image)? Great!
 The specific process will depend heavily on the Linux distribution you
 want to package. We have some examples below, and you are encouraged to
@@ -57,7 +57,7 @@ These options :
 - Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
 - Listen for connections on `tcp://192.168.59.3:2376`
-The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
+The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
 with explanations.
 ## Ubuntu
@@ -114,7 +114,7 @@ These options :
 - Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
 - Listen for connections on `tcp://192.168.59.3:2376`
-The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
+The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
 with explanations.
@@ -207,7 +207,7 @@ These options :
 - Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
 - Listen for connections on `tcp://192.168.59.3:2376`
-The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
+The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
 with explanations.
 5. Save and close the file.
@@ -1,86 +0,0 @@
 <!--[metadata]>
 +++
 title = "Accounts on Docker Hub"
 description = "Docker Hub accounts"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 1
 +++
 <![end-metadata]-->
 # Accounts on Docker Hub
 ## Docker Hub accounts
 You can `search` for Docker images and `pull` them from [Docker
 Hub](https://hub.docker.com) without signing in or even having an
 account. However, in order to `push` images, leave comments or to *star*
 a repository, you are going to need a [Docker
 Hub](https://hub.docker.com) account.
 ### Registration for a Docker Hub account
 You can get a [Docker Hub](https://hub.docker.com) account by
 [signing up for one here](https://hub.docker.com/account/signup/). A valid
 email address is required to register, which you will need to verify for
 account activation.
 ### Email activation process
 You need to have at least one verified email address to be able to use your
 [Docker Hub](https://hub.docker.com) account. If you can't find the validation email,
 you can request another by visiting the [Resend Email Confirmation](
 https://hub.docker.com/account/resend-email-confirmation/) page.
 ### Password reset process
 If you can't access your account for some reason, you can reset your password
 from the [*Password Reset*](https://hub.docker.com/account/forgot-password/)
 page.
 ## Organizations and groups
 A Docker Hub organization contains public and private repositories just like
 a user account. Access to push, pull or create these organisation owned repositories
 is allocated by defining groups of users and then assigning group rights to
 specific repositories. This allows you to distribute limited access
 Docker images, and to select which Docker Hub users can publish new images.
 ### Creating and viewing organizations
 You can see what organizations [you belong to and add new organizations](
 https://hub.docker.com/account/organizations/) from the Account Settings
 tab. They are also listed below your user name on your repositories page
 and in your account profile.
 ![organizations](/docker-hub/hub-images/orgs.png)
 ### Organization groups
 Users in the `Owners` group of an organization can create and modify the
 membership of groups.
 Unless they are the organization's `Owner`, users can only see groups of which they
 are members.
 ![groups](/docker-hub/hub-images/groups.png)
 ### Repository group permissions
 Use organization groups to manage the users that can interact with your repositories.
 You must be in an organization's `Owners` group to create a new group, Hub
 repository, or automated build. As an `Owner`, you then delegate the following
 repository access rights to groups:
 | Access Right | Description                                                                                                                                                                                                                                                                |
 |--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `Read`       | Users with this right can view, search, and pull a private repository.                                                                                                                                                                                                     |
 | `Write`      | Users with this right can push to non-automated repositories on the Docker Hub.                                                                                                                                                                                            |
 | `Admin`      | Users with this right can modify a repository's "Description", "Collaborators" rights. They can also mark a repository as unlisted, change its  "Public/Private" status and "Delete" the repository. Finally, `Admin` rights are required to read the build log on a repo. |
 |              |                                                                                                                                                                                                                                                                            |
 Regardless of their actual access rights, users with unverified email addresses
 have `Read` access to the repository. Once they have verified their address,
 they have their full access rights as granted on the organization.
@@ -1,465 +0,0 @@
 <!--[metadata]>
 +++
 title = "Automated Builds on Docker Hub"
 description = "Docker Hub Automated Builds"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, trusted, builds, trusted builds,  automated builds"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 3
 +++
 <![end-metadata]-->
 # Automated Builds on Docker Hub
 ## About Automated Builds
 *Automated Builds* are a special feature of Docker Hub which allow you to
 use [Docker Hub's](https://hub.docker.com) build clusters to automatically
 create images from a GitHub or Bitbucket repository containing a `Dockerfile`
 The system will clone your repository and build the image described by the
 `Dockerfile` using the directory the `Dockerfile` is in (and subdirectories)
 as the build context. The resulting automated image will then be uploaded
 to the Docker Hub registry and marked as an *Automated Build*.
 Automated Builds have several advantages:
 * Users of *your* Automated Build can trust that the resulting
 image was built exactly as specified.
 * The `Dockerfile` will be available to anyone with access to
 your repository on the Docker Hub registry.
 * Because the process is automated, Automated Builds help to
 make sure that your repository is always up to date.
 * Not having to push local Docker images to Docker Hub saves 
 you both network bandwidth and time.
 Automated Builds are supported for both public and private repositories
 on both [GitHub](http://github.com) and [Bitbucket](https://bitbucket.org/).
 To use Automated Builds, you must have an [account on Docker Hub](
 https://docs.docker.com/userguide/dockerhub/#creating-a-docker-hub-account)
 and on GitHub and/or Bitbucket. In either case, the account needs
 to be properly validated and activated before you can link to it.
 The first time you to set up an Automated Build, your
 [Docker Hub](https://hub.docker.com) account will need to be linked to
 a GitHub or Bitbucket account.
 This will allow the registry to see your repositories.
 If you have previously linked your Docker Hub account, and want to view or modify
 that link, click on the "Manage - Settings" link in the sidebar, and then
 "Linked Accounts" in your Settings sidebar.
 ## Automated Builds from GitHub
 If you've previously linked your Docker Hub account to your GitHub account,
 you'll be able to skip to the [Creating an Automated Build](#creating-an-automated-build).
 ### Linking your Docker Hub account to a GitHub account
 > *Note:*
 > Automated Builds currently require *read* and *write* access since
 > [Docker Hub](https://hub.docker.com) needs to setup a GitHub service
 > hook. We have no choice here, this is how GitHub manages permissions, sorry!
 > We do guarantee nothing else will be touched in your account.
 To get started, log into your Docker Hub account and click the
 "+ Add Repository" button at the upper right of the screen. Then select
 [Automated Build](https://registry.hub.docker.com/builds/add/).
 Select the [GitHub service](https://registry.hub.docker.com/associate/github/).
 When linking to GitHub, you'll need to select either "Public and Private",
 or "Limited" linking.
 The "Public and Private" option is the easiest to use,
 as it grants the Docker Hub full access to all of your repositories. GitHub
 also allows you to grant access to repositories belonging to your GitHub
 organizations.
 By choosing the "Limited" linking, your Docker Hub account only gets permission
 to access your public data and public repositories.
 Follow the onscreen instructions to authorize and link your
 GitHub account to Docker Hub. Once it is linked, you'll be able to
 choose a source repository from which to create the Automatic Build.
 You will be able to review and revoke Docker Hub's access by visiting the
 [GitHub User's Applications settings](https://github.com/settings/applications).
 > **Note**: If you delete the GitHub account linkage that is used for one of your
 > automated build repositories, the previously built images will still be available.
 > If you re-link to that GitHub account later, the automated build can be started
 > using the "Start Build" button on the Hub, or if the webhook on the GitHub repository
 > still exists, will be triggered by any subsequent commits.
 ### Auto builds and limited linked GitHub accounts.
 If you selected to link your GitHub account with only a "Limited" link, then
 after creating your automated build, you will need to either manually trigger a
 Docker Hub build using the "Start a Build" button, or add the GitHub webhook
 manually, as described in [GitHub Service Hooks](#github-service-hooks).
 ### Changing the GitHub user link
 If you want to remove, or change the level of linking between your GitHub account
 and the Docker Hub, you need to do this in two places.
 First, remove the "Linked Account" from your Docker Hub "Settings".
 Then go to your GitHub account's Personal settings, and in the "Applications"
 section, "Revoke access".
 You can now re-link your account at any time.
 ### GitHub organizations
 GitHub organizations and private repositories forked from organizations will be
 made available to auto build using the "Docker Hub Registry" application, which
 needs to be added to the organization - and then will apply to all users.
 To check, or request access, go to your GitHub user's "Setting" page, select the
 "Applications" section from the left side bar, then click the "View" button for
 "Docker Hub Registry".
 ![Check User access to GitHub](/docker-hub/hub-images/gh-check-user-org-dh-app-access.png)
 The organization's administrators may need to go to the Organization's "Third
 party access" screen in "Settings" to Grant or Deny access to the Docker Hub
 Registry application. This change will apply to all organization members.
 ![Check Docker Hub application access to Organization](/docker-hub/hub-images/gh-check-admin-org-dh-app-access.png)
 More detailed access controls to specific users and GitHub repositories would be
 managed using the GitHub People and Teams interfaces.
 ### Creating an Automated Build
 You can [create an Automated Build](
 https://registry.hub.docker.com/builds/github/select/) from any of your
 public or private GitHub repositories that have a `Dockerfile`.
 Once you've selected the source repository, you can then configure:
 - The Hub user/org the repository is built to - either your Hub account name,
 or the name of any Hub organizations your account is in
 - The Docker repository name the image is built to
 - If the Docker repository should be "Public" or "Private"
  You can change the accessibility options after the repository has been created.
  If you add a Private repository to a Hub user, then you can only add other users
  as collaborators, and those users will be able to view and pull all images in that 
  repository. To configure more granular access permissions, such as using groups of 
  users or allow different users access to different image tags, then you need
  to add the Private repository to a Hub organization that your user has Administrator
  privilege on.
 - If you want the GitHub to notify the Docker Hub when a commit is made, and thus trigger
  a rebuild of all the images in this automated build.
 You can also select one or more
 - The git branch/tag, which repository sub-directory to use as the context
 - The Docker image tag name
 You can set a description for the repository by clicking "Description" link in the righthand side bar after the automated build - note that the "Full Description" will be over-written next build from the README.md file.
 has been created.
 ### GitHub private submodules
 If your GitHub repository contains links to private submodules, you'll get an
 error message in your build.
 Normally, the Docker Hub sets up a deploy key in your GitHub repository.
 Unfortunately, GitHub only allows a repository deploy key to access a single repository.
 To work around this, you need to create a dedicated user account in GitHub and attach
 the automated build's deploy key that account. This dedicated build account
 can be limited to read-only access to just the repositories required to build.
 <table class="table table-bordered">
  <thead>
    <tr>
      <th>Step</th>
      <th>Screenshot</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1.</td>
      <td><img src="/docker-hub/hub-images/gh_org_members.png"></td>
      <td>First, create the new account in GitHub. It should be given read-only
      access to the main repository and all submodules that are needed.</td>
    </tr>
    <tr>
      <td>2.</td>
      <td><img src="/docker-hub/hub-images/gh_team_members.png"></td>
      <td>This can be accomplished by adding the account to a read-only team in
      the organization(s) where the main GitHub repository and all submodule
      repositories are kept.</td>
    </tr>
    <tr>
      <td>3.</td>
      <td><img src="/docker-hub/hub-images/gh_repo_deploy_key.png"></td>
      <td>Next, remove the deploy key from the main GitHub repository. This can be done in the GitHub repository's "Deploy keys" Settings section.</td>
    </tr>
    <tr>
      <td>4.</td>
      <td><img src="/docker-hub/hub-images/deploy_key.png"></td>
      <td>Your automated build's deploy key is in the "Build Details" menu
      under "Deploy keys".</td>
    </tr>
    <tr>
      <td>5.</td>
      <td><img src="/docker-hub/hub-images/gh_add_ssh_user_key.png"></td>
      <td>In your dedicated GitHub User account, add the deploy key from your
      Docker Hub Automated Build.</td>
    </tr>
  </tbody>
 </table>
 ### GitHub service hooks
 The GitHub Service hook allows GitHub to notify the Docker Hub when something has
 been committed to that git repository. You will need to add the Service Hook manually
 if your GitHub account is "Limited" linked to the Docker Hub.
 Follow the steps below to configure the GitHub Service hooks for your Automated Build:
 <table class="table table-bordered">
  <thead>
    <tr>
      <th>Step</th>
      <th>Screenshot</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1.</td>
      <td><img src="/docker-hub/hub-images/gh_settings.png"></td>
      <td>Log in to GitHub.com, and go to your Repository page. Click on "Settings" on
      the right side of the page. You must have admin privileges to the repository in order to do this.</td>
    </tr>
    <tr>
      <td>2.</td>
      <td><img src="/docker-hub/hub-images/gh_menu.png" alt="Webhooks & Services"></td>
      <td>Click on "Webhooks & Services" on the left side of the page.</td></tr>
      <tr><td>3.</td>
      <td><img src="/docker-hub/hub-images/gh_service_hook.png" alt="Find the service labeled Docker"></td>
      <td>Find the service labeled "Docker" (or click on "Add service") and click on it.</td></tr>
      <tr><td>4.</td>
      <td><img src="/docker-hub/hub-images/gh_docker-service.png" alt="Activate Service Hooks"></td>
      <td>Make sure the "Active" checkbox is selected and click the "Update service" button to save your changes.</td>
    </tr>
  </tbody>
 </table>
 ## Automated Builds with Bitbucket
 In order to setup an Automated Build, you need to first link your
 [Docker Hub](https://hub.docker.com) account with a Bitbucket account.
 This will allow the registry to see your repositories.
 To get started, log into your Docker Hub account and click the
 "+ Add Repository" button at the upper right of the screen. Then
 select [Automated Build](https://registry.hub.docker.com/builds/add/).
 Select the [Bitbucket source](
 https://registry.hub.docker.com/associate/bitbucket/).
 Then follow the onscreen instructions to authorize and link your
 Bitbucket account to Docker Hub. Once it is linked, you'll be able
 to choose a repository from which to create the Automatic Build.
 ### Creating an Automated Build
 You can [create an Automated Build](
 https://registry.hub.docker.com/builds/bitbucket/select/) from any of your
 public or private Bitbucket repositories with a `Dockerfile`.
 ### Adding a Hook
 When you link your Docker Hub account, a `POST` hook should get automatically
 added to your Bitbucket repository. Follow the steps below to confirm or modify the
 Bitbucket hooks for your Automated Build:
 <table class="table table-bordered">
  <thead>
    <tr>
      <th>Step</th>
      <th>Screenshot</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1.</td>
      <td><img src="/docker-hub/hub-images/bb_menu.png" alt="Settings" width="180"></td>
      <td>Log in to Bitbucket.org and go to your Repository page. Click on "Settings" on
      the far left side of the page, under "Navigation". You must have admin privileges
      to the repository in order to do this.</td>
    </tr>
    <tr>
      <td>2.</td>
      <td><img src="/docker-hub/hub-images/bb_hooks.png" alt="Hooks" width="180"></td>
      <td>Click on "Hooks" on the near left side of the page, under "Settings".</td></tr>
    <tr>
      <td>3.</td>
      <td><img src="/docker-hub/hub-images/bb_post-hook.png" alt="Docker Post Hook"></td><td>You should now see a list of hooks associated with the repo, including a <code>POST</code> hook that points at
      registry.hub.docker.com/hooks/bitbucket.</td>
    </tr>
  </tbody>
 </table>
 ## The Dockerfile and Automated Builds
 During the build process, Docker will copy the contents of your `Dockerfile`.
 It will also add it to the [Docker Hub](https://hub.docker.com) for the Docker
 community (for public repositories) or approved team members/orgs (for private
 repositories) to see on the repository page.
 ### README.md
 If you have a `README.md` file in your repository, it will be used as the
 repository's full description.The build process will look for a
 `README.md` in the same directory as your `Dockerfile`.
 > **Warning:**
 > If you change the full description after a build, it will be
 > rewritten the next time the Automated Build has been built. To make changes,
 > modify the `README.md` from the Git repository.
 ## Remote Build triggers
 If you need a way to trigger Automated Builds outside of GitHub or Bitbucket,
 you can set up a build trigger. When you turn on the build trigger for an
 Automated Build, it will give you a URL to which you can send POST requests.
 This will trigger the Automated Build, much as with a GitHub webhook.
 Build triggers are available under the Settings menu of each Automated Build
 repository on the Docker Hub.
 ![Build trigger screen](/docker-hub/hub-images/build-trigger.png)
 You can use `curl` to trigger a build:
 ```
 $ curl --data "build=true" -X POST https://registry.hub.docker.com/u/svendowideit/testhook/trigger/be579c
 82-7c0e-11e4-81c4-0242ac110020/
 OK
 ```
 > **Note:**
 > You can only trigger one build at a time and no more than one
 > every five minutes. If you already have a build pending, or if you
 > recently submitted a build request, those requests *will be ignored*.
 > To verify everything is working correctly, check the logs of last
 > ten triggers on the settings page .
 ## Webhooks
 Automated Builds also include a Webhooks feature. Webhooks can be called
 after a successful repository push is made. This includes when a new tag is added
 to an existing image.
 The webhook call will generate a HTTP POST with the following JSON
 payload:
 ```
 {
  "callback_url": "https://registry.hub.docker.com/u/svendowideit/testhook/hook/2141b5bi5i5b02bec211i4eeih0242eg11000a/",
  "push_data": {
    "images": [
        "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
        "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
        ...
    ],
    "pushed_at": 1.417566161e+09,
    "pusher": "trustedbuilder"
  },
  "repository": {
    "comment_count": 0,
    "date_created": 1.417494799e+09,
    "description": "",
    "dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\nMAINTAINER\u0009SvenDowideit@home.org.au\n\n\nVOLUME\u0009\u0009[\"/var/cache/apt-cacher-ng\"]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n",
    "full_description": "Docker Hub based automated build from a GitHub repo",
    "is_official": false,
    "is_private": true,
    "is_trusted": true,
    "name": "testhook",
    "namespace": "svendowideit",
    "owner": "svendowideit",
    "repo_name": "svendowideit/testhook",
    "repo_url": "https://registry.hub.docker.com/u/svendowideit/testhook/",
    "star_count": 0,
    "status": "Active"
  }
 }
 ```
 Webhooks are available under the Settings menu of each Repository.  
 Use a tool like [requestb.in](http://requestb.in/) to test your webhook.
 > **Note**: The Docker Hub servers use an elastic IP range, so you can't
 > filter requests by IP.
 ### Webhook chains
 Webhook chains allow you to chain calls to multiple services. For example,
 you can use this to trigger a deployment of your container only after
 it has been successfully tested, then update a separate Changelog once the
 deployment is complete.
 After clicking the "Add webhook" button, simply add as many URLs as necessary
 in your chain.
 The first webhook in a chain will be called after a successful push. Subsequent
 URLs will be contacted after the callback has been validated.
 ### Validating a callback
 In order to validate a callback in a webhook chain, you need to
 1. Retrieve the `callback_url` value in the request's JSON payload.
 1. Send a POST request to this URL containing a valid JSON body.
 > **Note**: A chain request will only be considered complete once the last
 > callback has been validated.
 To help you debug or simply view the results of your webhook(s),
 view the "History" of the webhook available on its settings page.
 ### Callback JSON data
 The following parameters are recognized in callback data:
 * `state` (required): Accepted values are `success`, `failure` and `error`.
  If the state isn't `success`, the webhook chain will be interrupted.
 * `description`: A string containing miscellaneous information that will be
  available on the Docker Hub. Maximum 255 characters.
 * `context`: A string containing the context of the operation. Can be retrieved
  from the Docker Hub. Maximum 100 characters.
 * `target_url`: The URL where the results of the operation can be found. Can be
  retrieved on the Docker Hub.
 *Example callback payload:*
    {
      "state": "success",
      "description": "387 tests PASSED",
      "context": "Continuous integration by Acme CI",
      "target_url": "http://ci.acme.com/results/afd339c1c3d27"
    }
 ## Repository links
 Repository links are a way to associate one Automated Build with
 another. If one gets updated, the linking system triggers a rebuild
 for the other Automated Build. This makes it easy to keep all your
 Automated Builds up to date.
 To add a link, go to the repository for the Automated Build you want to
 link to and click on *Repository Links* under the Settings menu at
 right. Then, enter the name of the repository that you want have linked.
 > **Warning:**
 > You can add more than one repository link, however, you should
 > do so very carefully. Creating a two way relationship between Automated Builds will
 > cause an endless build loop.
@@ -1,20 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "The Docker Hub Registry help"
 description = "The Docker Registry help documentation home"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 +++
 <![end-metadata]-->
 # The Docker Hub Registry help
 ## Introduction
 For your questions about the [Docker Hub](https://hub.docker.com) registry you
 can use [this documentation](docs.md).
 If you can not find something you are looking for, please feel free to
 [contact us](https://docker.com/resources/support/).
@@ -1,38 +0,0 @@
 <!--[metadata]>
 +++
 title = "The Docker Hub"
 description = "The Docker Help documentation home"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, accounts, organizations, repositories,  groups"]
 [menu.main]
 parent = "smn_pubhub"
 +++
 <![end-metadata]-->
 # Docker Hub
 The [Docker Hub](https://hub.docker.com) provides a cloud-based platform service
 for distributed applications, including container image distribution and change
 management, user and team collaboration, and lifecycle workflow automation.
 ![DockerHub](/docker-hub/hub-images/hub.png)
 ## [Finding and pulling images](./userguide.md)
 Find out how to [use the Docker Hub](./userguide.md) to find and pull Docker
 images to run or build upon.
 ## [Accounts](./accounts.md)
 [Learn how to create](./accounts.md) a Docker Hub
 account and manage your organizations and groups.
 ## [Your Repositories](./repos.md)
 Find out how to share your Docker images in [Docker Hub
 repositories](./repos.md) and how to store and manage private images.
 ## [Automated builds](./builds.md)
 Learn how to automate your build and deploy pipeline with [Automated
 Builds](./builds.md)
@@ -1,113 +0,0 @@
 <!--[metadata]>
 +++
 title = "Official Repositories on Docker Hub"
 description = "Guidelines for Official Repositories on Docker Hub"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, official, image,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 4
 +++
 <![end-metadata]-->
 # Official Repositories on Docker Hub
 The Docker [Official Repositories](http://registry.hub.docker.com/official) are
 a curated set of Docker repositories that are promoted on Docker Hub. They are
 designed to:
 * Provide essential base OS repositories (for example,
  [`ubuntu`](https://registry.hub.docker.com/_/ubuntu/),
  [`centos`](https://registry.hub.docker.com/_/centos/)) that serve as the
  starting point for the majority of users.
 * Provide drop-in solutions for popular programming language runtimes, data
  stores, and other services, similar to what a Platform-as-a-Service (PAAS)
  would offer.
 * Exemplify [`Dockerfile` best practices](/articles/dockerfile_best-practices)
  and provide clear documentation to serve as a reference for other `Dockerfile`
  authors.
 * Ensure that security updates are applied in a timely manner. This is
  particularly important as many Official Repositories are some of the most
  popular on Docker Hub.
 * Provide a channel for software vendors to redistribute up-to-date and
  supported versions of their products. Organization accounts on Docker Hub can
  also serve this purpose, without the careful review or restrictions on what
  can be published.
 Docker, Inc. sponsors a dedicated team that is responsible for reviewing and
 publishing all Official Repositories content. This team works in collaboration
 with upstream software maintainers, security experts, and the broader Docker
 community.
 While it is preferable to have upstream software authors maintaining their
 corresponding Official Repositories, this is not a strict requirement. Creating
 and maintaining images for Official Repositories is a public process. It takes
 place openly on GitHub where participation is encouraged. Anyone can provide
 feedback, contribute code, suggest process changes, or even propose a new
 Official Repository.
 ## Should I use Official Repositories?
 New Docker users are encouraged to use the Official Repositories in their
 projects. These repositories have clear documentation, promote best practices,
 and are designed for the most common use cases. Advanced users are encouraged to
 review the Official Repositories as part of their `Dockerfile` learning process.
 A common rationale for diverging from Official Repositories is to optimize for
 image size. For instance, many of the programming language stack images contain
 a complete build toolchain to support installation of modules that depend on
 optimized code. An advanced user could build a custom image with just the
 necessary pre-compiled libraries to save space.
 A number of language stacks such as
 [`python`](https://registry.hub.docker.com/_/python/) and
 [`ruby`](https://registry.hub.docker.com/_/ruby/) have `-slim` tag variants
 designed to fill the need for optimization.  Even when these "slim" variants are
 insufficient, it is still recommended to inherit from an Official Repository
 base OS image to leverage the ongoing maintenance work, rather than duplicating
 these efforts.
 ## How can I get involved?
 All Official Repositories contain a **User Feedback** section in their
 documentation which covers the details for that specific repository. In most
 cases, the GitHub repository which contains the Dockerfiles for an Official
 Repository also has an active issue tracker. General feedback and support
 questions should be directed to `#docker-library` on Freenode IRC.
 ## How do I create a new Official Repository?
 From a high level, an Official Repository starts out as a proposal in the form
 of a set of GitHub pull requests.  You'll find detailed and objective proposal
 requirements in the following GitHub repositories:
 * [docker-library/official-images](https://github.com/docker-library/official-images)
 * [docker-library/docs](https://github.com/docker-library/docs)
 The Official Repositories team, with help from community contributors, formally
 review each proposal and provide feedback to the author. This initial review
 process may require a bit of back and forth before the proposal is accepted.
 There are also subjective considerations during the review process. These
 subjective concerns boil down to the basic question: "is this image generally
 useful?"  For example, the [`python`](https://registry.hub.docker.com/_/python/)
 Official Repository is "generally useful" to the large Python developer
 community, whereas an obscure text adventure game written in Python last week is
 not.
 When a new proposal is accepted, the author becomes responsible for keeping
 their images up-to-date and responding to user feedback.  The Official
 Repositories team becomes responsible for publishing the images and
 documentation on Docker Hub.  Updates to the Official Repository follow the same
 pull request process, though with less review. The Official Repositories team
 ultimately acts as a gatekeeper for all changes, which helps mitigate the risk
 of quality and security issues from being introduced.
 > **Note**: If you are interested in proposing an Official Repository, but would
 > like to discuss it with Docker, Inc. privately first, please send your
 > inquiries to partners@docker.com.  There is no fast-track or pay-for-status
 > option.
@@ -1,193 +0,0 @@
 <!--[metadata]>
 +++
 title = "Your Repositories on Docker Hub"
 description = "Your Repositories on Docker Hub"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, webhooks, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 2
 +++
 <![end-metadata]-->
 # Your Hub repositories
 Docker Hub repositories make it possible for you to share images with co-workers,
 customers or the Docker community at large. If you're building your images internally,
 either on your own Docker daemon, or using your own Continuous integration services,
 you can push them to a Docker Hub repository that you add to your Docker Hub user or
 organization account.
 Alternatively, if the source code for your Docker image is on GitHub or Bitbucket,
 you can use an "Automated build" repository, which is built by the Docker Hub
 services. See the [automated builds documentation](./builds.md) to read about
 the extra functionality provided by those services.
 ![repositories](/docker-hub/hub-images/repos.png)
 Your Docker Hub repositories have a number of useful features.
 ## Stars
 Your repositories can be starred and you can star repositories in
 return. Stars are a way to show that you like a repository. They are
 also an easy way of bookmarking your favorites.
 ## Comments
 You can interact with other members of the Docker community and maintainers by
 leaving comments on repositories. If you find any comments that are not
 appropriate, you can flag them for review.
 ## Collaborators and their role
 A collaborator is someone you want to give access to a private
 repository. Once designated, they can `push` and `pull` to your
 repositories. They will not be allowed to perform any administrative
 tasks such as deleting the repository or changing its status from
 private to public.
 > **Note:**
 > A collaborator cannot add other collaborators. Only the owner of
 > the repository has administrative access.
 You can also assign more granular collaborator rights ("Read", "Write", or "Admin")
 on Docker Hub by using organizations and groups. For more information
 see the [accounts documentation](accounts/).
 ## Private repositories
 Private repositories allow you to have repositories that contain images
 that you want to keep private, either to your own account or within an
 organization or group.
 To work with a private repository on [Docker
 Hub](https://hub.docker.com), you will need to add one via the [Add
 Repository](https://registry.hub.docker.com/account/repositories/add/)
 link. You get one private repository for free with your Docker Hub
 account. If you need more accounts you can upgrade your [Docker
 Hub](https://registry.hub.docker.com/plans/) plan.
 Once the private repository is created, you can `push` and `pull` images
 to and from it using Docker.
 > *Note:* You need to be signed in and have access to work with a
 > private repository.
 Private repositories are just like public ones. However, it isn't
 possible to browse them or search their content on the public registry.
 They do not get cached the same way as a public repository either.
 It is possible to give access to a private repository to those whom you
 designate (i.e., collaborators) from its Settings page. From there, you
 can also switch repository status (*public* to *private*, or
 vice-versa). You will need to have an available private repository slot
 open before you can do such a switch. If you don't have any available,
 you can always upgrade your [Docker
 Hub](https://registry.hub.docker.com/plans/) plan.
 ## Webhooks
 A webhook is an HTTP call-back triggered by a specific event.
 You can use a Hub repository webhook to notify people, services, and other
 applications after a new image is pushed to your repository (this also happens
 for Automated builds). For example, you can trigger an automated test or
 deployment to happen as soon as the image is available.
 To get started adding webhooks, go to the desired repository in the Hub,
 and click "Webhooks" under the "Settings" box.
 A webhook is called only after a successful `push` is
 made. The webhook calls are HTTP POST requests with a JSON payload
 similar to the example shown below.
 *Example webhook JSON payload:*
 ```
 {
  "callback_url": "https://registry.hub.docker.com/u/svendowideit/busybox/hook/2141bc0cdec4hebec411i4c1g40242eg110020/",
  "push_data": {
    "images": [
        "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
        "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
        ...
    ],
    "pushed_at": 1.417566822e+09,
    "pusher": "svendowideit"
  },
  "repository": {
    "comment_count": 0,
    "date_created": 1.417566665e+09,
    "description": "",
    "full_description": "webhook triggered from a 'docker push'",
    "is_official": false,
    "is_private": false,
    "is_trusted": false,
    "name": "busybox",
    "namespace": "svendowideit",
    "owner": "svendowideit",
    "repo_name": "svendowideit/busybox",
    "repo_url": "https://registry.hub.docker.com/u/svendowideit/busybox/",
    "star_count": 0,
    "status": "Active"
 }
 ```
 <TODO: does it tell you what tag was updated?>
 For testing, you can try an HTTP request tool like [requestb.in](http://requestb.in/).
 > **Note**: The Docker Hub servers use an elastic IP range, so you can't
 > filter requests by IP.
 ### Webhook chains
 Webhook chains allow you to chain calls to multiple services. For example,
 you can use this to trigger a deployment of your container only after
 it has been successfully tested, then update a separate Changelog once the
 deployment is complete.
 After clicking the "Add webhook" button, simply add as many URLs as necessary
 in your chain.
 The first webhook in a chain will be called after a successful push. Subsequent
 URLs will be contacted after the callback has been validated.
 ### Validating a callback
 In order to validate a callback in a webhook chain, you need to
 1. Retrieve the `callback_url` value in the request's JSON payload.
 1. Send a POST request to this URL containing a valid JSON body.
 > **Note**: A chain request will only be considered complete once the last
 > callback has been validated.
 To help you debug or simply view the results of your webhook(s),
 view the "History" of the webhook available on its settings page.
 #### Callback JSON data
 The following parameters are recognized in callback data:
 * `state` (required): Accepted values are `success`, `failure` and `error`.
  If the state isn't `success`, the webhook chain will be interrupted.
 * `description`: A string containing miscellaneous information that will be
  available on the Docker Hub. Maximum 255 characters.
 * `context`: A string containing the context of the operation. Can be retrieved
  from the Docker Hub. Maximum 100 characters.
 * `target_url`: The URL where the results of the operation can be found. Can be
  retrieved on the Docker Hub.
 *Example callback payload:*
    {
      "state": "success",
      "description": "387 tests PASSED",
      "context": "Continuous integration by Acme CI",
      "target_url": "http://ci.acme.com/results/afd339c1c3d27"
    }
 ## Mark as unlisted
 By marking a repository as unlisted, you can create a publicly pullable repository
 which will not be in the Hub or commandline search. This allows you to have a limited
 release, but does not restrict access to anyone that is told, or guesses the repository
 name.
@@ -1,63 +0,0 @@
 <!--[metadata]>
 +++
 title = "Docker Hub user guide"
 description = "Docker Hub user guide"
 keywords = ["Docker, docker, registry, Docker Hub, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 +++
 <![end-metadata]-->
 # Using the Docker Hub
 Docker Hub is used to find and pull Docker images to run or build upon, and to
 distribute and build images for other users to use.
 ![your profile](/docker-hub/hub-images/dashboard.png)
 ## Finding repositories and images
 There are two ways you can search for public repositories and images available
 on the Docker Hub. You can use the "Search" tool on the Docker Hub website, or
 you can `search` for all the repositories and images using the Docker commandline
 tool:
    $ docker search ubuntu
 Both will show you a list of the currently available public repositories on the
 Docker Hub which match the provided keyword.
 If a repository is private or marked as unlisted, it won't be in the repository
 search results. To see all the repositories you have access to and their statuses,
 you can look at your profile page on [Docker Hub](https://hub.docker.com).
 ## Pulling, running and building images
 You can find more information on [working with Docker images](../userguide/dockerimages.md).
 ## Official Repositories
 The Docker Hub contains a number of [Official
 Repositories](http://registry.hub.docker.com/official). These are
 certified repositories from vendors and contributors to Docker. They
 contain Docker images from vendors like Canonical, Oracle, and Red Hat
 that you can use to build applications and services.
 If you use Official Repositories you know you're using an optimized and
 up-to-date image to power your applications.
 > **Note:**
 > If you would like to contribute an Official Repository for your
 > organization, see [Official Repositories on Docker
 > Hub](/docker-hub/official_repos) for more information.
 ## Building and shipping your own repositories and images
 The Docker Hub provides you and your team with a place to build and ship Docker images.
 Collections of Docker images are managed using repositories - 
 You can configure two types of repositories to manage on the Docker Hub:
 [Repositories](./repos.md), which allow you to push images to the Hub from your local Docker daemon,
 and [Automated Builds](./builds.md), which allow you to configure GitHub or Bitbucket to
 trigger the Hub to rebuild repositories when changes are made to the repository.
@@ -21,7 +21,7 @@ installation mechanisms. Using these packages ensures you get the latest release
 of Docker. If you wish to install using Fedora-managed packages, consult your
 Fedora release documentation for information on Fedora's Docker support.
-##Prerequisites
+## Prerequisites
 Docker requires a 64-bit installation regardless of your Fedora version. Also, your kernel must be 3.10 at minimum. To check your current kernel
 version, open a terminal and use `uname -r` to display your kernel version:
@@ -72,38 +72,38 @@ installer.
 and choosing "Open" from the pop-up menu.
    The installer launches the "Install Docker Toolbox" dialog.
-
+    
    ![Install Docker Toolbox](/installation/images/mac-welcome-page.png)
 4. Press "Continue" to install the toolbox.
    The installer presents you with options to customize the standard
    installation. 
-
+  
    ![Standard install](/installation/images/mac-page-two.png)
-
+  
    By default, the standard Docker Toolbox installation:
-
+  
    * installs binaries for the Docker tools in `/usr/local/bin` 
    * makes these binaries available to all users 
    * updates any existing VirtualBox installation 
-
+  
    Change these defaults by pressing "Customize" or "Change
    Install Location."  
 5. Press "Install" to perform the standard installation.
     The system prompts you for your password.
-
+   
     ![Password prompt](/installation/images/mac-password-prompt.png)
-
+   
 6. Provide your password to continue with the installation.
     When it completes, the installer provides you with some information you can
     use to complete some common tasks.
-
+   
     ![All finished](/installation/images/mac-page-finished.png)
-
+   
 7. Press "Close" to exit.
@@ -134,9 +134,9 @@ There are two ways to use the installed tools, from the Docker Quickstart Termin
    * points the terminal environment to this VM
    Once the launch completes, the Docker Quickstart Terminal reports:
-
+    
     ![All finished](/installation/images/mac-success.png)
-
+     
    Now, you can run `docker` commands. 
 3. Verify your setup succeeded by running the `hello-world` container.
@@ -186,20 +186,20 @@ different shell such as C Shell but the commands are the same.
        To see how to connect Docker to this machine, run: docker-machine env default
    This creates a new `default` in VirtualBox.
-
+    
    ![default](/installation/images/default.png)
    The command also creates a machine configuration in the
    `~/.docker/machine/machines/default` directory. You only need to run the
    `create` command once. Then, you can use `docker-machine` to start, stop,
    query, and otherwise manage the VM from the command line.
-
+    
 2. List your available machines.
        $ docker-machine ls
        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
        default             *        virtualbox   Running   tcp://192.168.99.101:2376  
-
+        
    If you have previously installed the deprecated Boot2Docker application or
    run the Docker Quickstart Terminal, you may have a `dev` VM as well.  When you
    created `default`, the `docker-machine` command provided instructions
@@ -214,7 +214,7 @@ different shell such as C Shell but the commands are the same.
        export DOCKER_MACHINE_NAME="default"
        # Run this command to configure your shell: 
        # eval "$(docker-machine env default)"
-
+    
 4. Connect your shell to the `default` machine.
        $ eval "$(docker-machine env default)"
@@ -246,9 +246,9 @@ this older VM, you can migrate it.
 2. Type the following command.
        $ docker-machine create -d virtualbox --virtualbox-import-boot2docker-vm boot2docker-vm docker-vm
-
+      
 3. Use the `docker-machine` command to interact with the migrated VM.  
-
+      
 The `docker-machine` subcommands are slightly different than the `boot2docker`
 subcommands. The table below lists the equivalent `docker-machine` subcommand
 and what it does:
@@ -280,9 +280,9 @@ To verify this, run the following commands:
    $ docker-machine ls
    NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
-    dev                 *        virtualbox   Running   tcp://192.168.99.100:2376   
+    default             *        virtualbox   Running   tcp://192.168.99.100:2376   
-The `ACTIVE` machine, in this case `dev`, is the one your environment is pointing to.
+The `ACTIVE` machine, in this case `default`, is the one your environment is pointing to.
 ### Access container ports
@@ -319,9 +319,9 @@ The `ACTIVE` machine, in this case `dev`, is the one your environment is pointin
    not the localhost address (0.0.0.0) but is instead the address of the
    your Docker VM.
-5. Get the address of the `dev` VM.
+5. Get the address of the `default` VM.
-        $ docker-machine ip dev
+        $ docker-machine ip default
        192.168.59.103
 6. Enter the `http://192.168.59.103:49157` address in your browser:
@@ -408,7 +408,7 @@ To uninstall, do the following:
        $ docker-machine rm dev
        Successfully removed dev
-
+    
     Removing a machine deletes its VM from VirtualBox and from the
     `~/.docker/machine/machines` directory.
@@ -417,7 +417,7 @@ To uninstall, do the following:
 4. Remove the `docker`, `docker-compose`, and `docker-machine` commands from the `/usr/local/bin` folder.
        $ rm /usr/local/bin/docker
-
+      
 5. Delete the `~/.docker` folder from your system.
@@ -429,4 +429,4 @@ documentation](https://docs.docker.com/machine/).
 You can continue with the [Docker User Guide](/userguide). If you are
 interested in using the Kitematic GUI, see the [Kitermatic user
-guide](/kitematic/userguide/).
+guide](/kitematic/userguide/).
@@ -96,7 +96,7 @@ To upgrade your kernel and install the additional packages, do the following:
        $ sudo reboot
-5. After your system reboots, go ahead and [install Docker](#installing-docker-on-ubuntu).
+5. After your system reboots, go ahead and [install Docker](#installation).
 ### For Saucy 13.10 (64 bit)
@@ -36,7 +36,7 @@ Your machine must be running Windows 7.1, 8/8.1 or newer to run Docker. Windows
 1. Right click the Windows message and choose **System**. 
    ![Which version](/installation/images/win_ver.png)
-
+    
    If you aren't using a supported version, you could consider upgrading your
    operating system.
@@ -44,19 +44,19 @@ Your machine must be running Windows 7.1, 8/8.1 or newer to run Docker. Windows
    #### For Windows 8 or 8.1
-    Choose **Start > Task Manager** and navigate to the **Performance** tab.          
+	  Choose **Start > Task Manager** and navigate to the **Performance** tab.          
-    Under **CPU** you should see the following:
+	  Under **CPU** you should see the following:
      ![Release page](/installation/images/virtualization.png)
-
+    
    If virtualization is not enabled on your system, follow the manufacturer's instructions for enabling it.
-
+    
-    ### For Windows 7
+    ### For Windows 7 
-
+    
-    Run the <a
+	  Run the <a
-    href="http://www.microsoft.com/en-us/download/details.aspx?id=592"
+	  href="http://www.microsoft.com/en-us/download/details.aspx?id=592"
-    target="_blank"> Microsoft® Hardware-Assisted Virtualization Detection
+	  target="_blank"> Microsoft® Hardware-Assisted Virtualization Detection
-    Tool</a> and follow the on-screen instructions.
+	  Tool</a> and follow the on-screen instructions.
 > **Note**: If you have Docker hosts running and you don't wish to do a Docker Toolbox
@@ -101,14 +101,14 @@ installer.
 3. Install Docker Toolbox by double-clicking the installer.
    The installer launches the "Setup - Docker Toolbox" dialog.
-
+    
    ![Install Docker Toolbox](/installation/images/win-welcome.png)
 4. Press "Next" to install the toolbox.
    The installer presents you with options to customize the standard
    installation. By default, the standard Docker Toolbox installation:
-
+  
    * installs executables for the Docker tools in `C:\Program Files\Docker Toolbox` 
    * updates any existing VirtualBox installation 
    * adds a Docker Inc. folder to your program shortcuts
@@ -120,16 +120,16 @@ installer.
 5. Press "Next" until you reach the "Ready to Install" page.
     The system prompts you for your password.
-
+   
     ![Install](/installation/images/win-page-6.png)
-
+     
 6. Press "Install"  to continue with the installation.
     When it completes, the installer provides you with some information you can
     use to complete some common tasks.
-
+   
     ![All finished](/installation/images/windows-finish.png)
-
+   
 7. Press "Close" to exit.
 ## Running a Docker Container
@@ -198,7 +198,7 @@ There are several ways to use the installed tools, from the Docker Quickstart Te
 2. Add this to the `%PATH%` environment variable by running:
        set PATH=%PATH%;"c:\Program Files (x86)\Git\bin"
-
+        
 3. Create a new Docker VM.
        docker-machine create --driver virtualbox my-default
@@ -212,20 +212,20 @@ There are several ways to use the installed tools, from the Docker Quickstart Te
    `C:\USERS\USERNAME\.docker\machine\machines` directory. You only need to run the `create`
    command once. Then, you can use `docker-machine` to start, stop, query, and
    otherwise manage the VM from the command line.
-
+    
 4. List your available machines.
        C:\Users\mary> docker-machine ls
        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
        my-default        *        virtualbox   Running   tcp://192.168.99.101:2376  
-
+        
    If you have previously installed the deprecated Boot2Docker application or
    run the Docker Quickstart Terminal, you may have a `dev` VM as well.  
 5. Get the environment commands for your new VM.
        C:\Users\mary> docker-machine env --shell cmd my-default
-
+    
 6. Connect your shell to the `my-default` machine.
        C:\Users\mary> eval "$(docker-machine env my-default)"
@@ -241,21 +241,21 @@ There are several ways to use the installed tools, from the Docker Quickstart Te
 2. Add `ssh.exe` to your PATH:
        PS C:\Users\mary> $Env:Path = "${Env:Path};c:\Program Files (x86)\Git\bin"
-
+        
 3. Create a new Docker VM.
        PS C:\Users\mary> docker-machine create --driver virtualbox my-default
-
+    
 4. List your available machines.
        C:\Users\mary> docker-machine ls
        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
        my-default        *        virtualbox   Running   tcp://192.168.99.101:2376  
-
+      
 5. Get the environment commands for your new VM.
        C:\Users\mary> docker-machine env --shell powershell my-default
-
+    
 6. Connect your shell to the `my-default` machine.
        C:\Users\mary> eval "$(docker-machine env my-default)"
@@ -288,9 +288,9 @@ this older VM, you can migrate it.
 2. Type the following command.
        $ docker-machine create -d virtualbox --virtualbox-import-boot2docker-vm boot2docker-vm docker-vm
-
+      
 3. Use the `docker-machine` command to interact with the migrated VM.  
-
+      
 The `docker-machine` subcommands are slightly different than the `boot2docker`
 subcommands. The table below lists the equivalent `docker-machine` subcommand
 and what it does:
@@ -362,4 +362,4 @@ delete that file yourself.
 You can continue with the [Docker User Guide](/userguide). If you are
 interested in using the Kitematic GUI, see the [Kitermatic user
-guide](/kitematic/userguide/).
+guide](/kitematic/userguide/).
@@ -0,0 +1,107 @@
 #!/bin/bash -ex
 # Populate an array with just docker dirs and one with content dirs
 content_dir=(`ls -d /docs/content/*`)
 # Loop content not of docker/
 #
 # Sed to process GitHub Markdown
 # 1-2 Remove comment code from metadata block
 # 3 Remove .md extension from link text
 # 4 Change ](/ to ](/project/ in links
 # 5 Change ](word) to ](/project/word)
 # 6 Change ](../../ to ](/project/
 # 7 Change ](../ to ](/project/word)
 # 
 for i in "${content_dir[@]}"
 do
   :
   case $i in
      "/docs/content/docker-trusted-registry")
      ;;
      "/docs/content/docker-hub")
      ;;
      "/docs/content/windows")
      ;;
      "/docs/content/mac")
      ;;
      "/docs/content/linux")
      ;;
      "/docs/content/registry")
      y=${i##*/}
      find $i -type f -name "*.md" -not -name "*.compare.md" -exec sed -i.old \
        -e '/^<!\(--\)\{0,1\}\[\(end-\)\{0,1\}metadata\]\(--\)\{0,1\}>/g' \
        -e 's/\(\][(]\)\(\.*\/\)*/\1/g' \
        -e 's/\(\][(]\)\([A-Za-z0-9_/-]\{1,\}\)\(\.md\)\{0,1\}\(#\{0,1\}\(#[A-Za-z0-9_-]*\)\{0,1\}\)[)]/\1\/'$y'\/\2\4)/g' \
        {} \;
      ;;
      "/docs/content/compose")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;      
      ;;
      "/docs/content/swarm")
         y=${i##*/}
         find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;     
      ;;
      "/docs/content/machine")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;         
      ;;
      "/docs/content/kitematic")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;         
      ;;
      "/docs/content/opensource")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;         
      ;;
      *)
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' {} \;        
      ;;
      esac
 done
@@ -96,9 +96,9 @@ environment.
 1. Open a terminal.
-    Mac users, use `boot2docker status` to make sure Boot2Docker is running. You
+    Mac users, use `docker-machine status your_vm_name` to make sure your VM is
-    may need to run `eval "$(boot2docker shellinit)"` to initialize your shell
+    running. You may need to run `eval "$(docker-machine env your_vm_name)"` to
-    environment.
+    initialize your shell environment.
 3. Change into the root of your forked repository.
@@ -193,7 +193,7 @@ environment.
    Keeping the ancestor images improves the build performance. When you rebuild
    the child image, the build process uses the local ancestors rather than
    retrieving them from the Hub. The build process gets new ancestors only if
-    DockerHub has updated versions.
+    Docker Hub has updated versions.
 ## Start a container and run a test
@@ -0,0 +1,17 @@
 <!--[metadata]>
 +++
 title = "The Docker Hub and the Registry v1"
 description = "Documentation for docker Registry and Registry API"
 keywords = ["docker, registry, api,  hub"]
 [menu.main]
 parent="smn_hub_ref"
 +++
 <![end-metadata]-->
 # The Docker Hub and the Registry v1
 This API is deprecated as of 1.7. To view the old version, see the [go
 here](http://docs.docker.com/v1.7/reference/api/hub_registry_spec/) in
 the 1.7 documentation. If you want an overview of the current features in
 Docker Hub or other image management features see the [image management
 overview](/userguide/image_management/) in the current documentation set.
@@ -10,48 +10,50 @@ parent = "mn_reference"
 # Dockerfile reference
-**Docker can build images automatically** by reading the instructions
+Docker can build images automatically by reading the instructions from a
-from a `Dockerfile`. A `Dockerfile` is a text document that contains all
+`Dockerfile`. A `Dockerfile` is a text document that contains all the commands a
-the commands you would normally execute manually in order to build a
+user could call on the command line to assemble an image. Using `docker build`
-Docker image. By calling `docker build` from your terminal, you can have
+users can create an automated build that executes several command-line
-Docker build your image step by step, executing the instructions
+instructions in succession.
 successively.
-This page discusses the specifics of all the instructions you can use in your
+This page describes the commands you can use in a `Dockerfile`. When you are
-`Dockerfile`. To further help you write a clear, readable, maintainable
+done reading this page, refer to the [`Dockerfile` Best
-`Dockerfile`, we've also written a [`Dockerfile` Best Practices
+Practices](/articles/dockerfile_best-practices) for a tip-oriented guide.
 guide](/articles/dockerfile_best-practices). Lastly, you can test your
 Dockerfile knowledge with the [Dockerfile tutorial](/userguide/level1).
 ## Usage
-To [*build*](/reference/commandline/cli/#build) an image from a source repository,
+The [`docker build`](/reference/commandline/build/) command builds an image from
-create a description file called `Dockerfile` at the root of your repository.
+a `Dockerfile` and a *context*. The build's context is the files at a specified
-This file will describe the steps to assemble the image.
+location `PATH` or `URL`. The `PATH` is a directory on your local filesystem.
 The `URL` is a the location of a Git repository.
-Then call `docker build` with the path of your source repository as the argument
+A context is processed recursively. So, a `PATH` includes any subdirectories and
-(for example, `.`):
+the `URL` includes the repository and its submodules. A simple build command
 that uses the current directory as context:
    $ docker build .
    Sending build context to Docker daemon  6.51 MB
    ...
-The path to the source repository defines where to find the *context* of
+The build is run by the Docker daemon, not by the CLI. The first thing a build
-the build. The build is run by the Docker daemon, not by the CLI, so the
+process does is send the entire context (recursively) to the daemon.  In most
-whole context must be transferred to the daemon. The Docker CLI reports
+cases, it's best to start with an empty directory as context and keep your
-"Sending build context to Docker daemon" when the context is sent to the daemon.
+Dockerfile in that directory. Add only the files needed for building the
 Dockerfile.
-> **Warning**
+>**Warning**: Do not use your root directory, `/`, as the `PATH` as it causes
-> Avoid using your root directory, `/`, as the root of the source repository. The 
+>the build to transfer the entire contents of your hard drive to the Docker
-> `docker build` command will use whatever directory contains the Dockerfile as the build
+>daemon. 
 > context (including all of its subdirectories). The build context will be sent to the
 > Docker daemon before building the image, which means if you use `/` as the source
 > repository, the entire contents of your hard drive will get sent to the daemon (and
 > thus to the machine running the daemon). You probably don't want that.
-In most cases, it's best to put each Dockerfile in an empty directory. Then,
+To use a file in the build context, the `Dockerfile` refers to the file with
-only add the files needed for building the Dockerfile to the directory. To
+an instruction, for example,  a `COPY` instruction. To increase the build's
-increase the build's performance, you can exclude files and directories by
+performance, exclude files and directories by adding a `.dockerignore` file to
-adding a `.dockerignore` file to the directory.  For information about how to
+the context directory.  For information about how to [create a `.dockerignore`
-[create a `.dockerignore` file](#dockerignore-file) on this page.
+file](#dockerignore-file) see the documentation on this page.
 Traditionally, the `Dockerfile` is called `Dockerfile` and located in the root
 of the context. You use the `-f` flag with `docker build` to point to a Dockerfile
 anywhere in your file system.
 You can specify a repository and tag at which to save the new image if
 the build succeeds:
@@ -100,7 +102,7 @@ be UPPERCASE in order to distinguish them from arguments more easily.
 Docker runs the instructions in a `Dockerfile` in order. **The
 first instruction must be \`FROM\`** in order to specify the [*Base
-Image*](/terms/image/#base-image) from which you are building.
+Image*](/reference/glossary/#base-image) from which you are building.
 Docker will treat lines that *begin* with `#` as a
 comment. A `#` marker anywhere else in the line will
@@ -160,13 +162,13 @@ The instructions that handle environment variables in the `Dockerfile` are:
 the instructions above.
 Environment variable substitution will use the same value for each variable
-throughout the entire command.  In other words, in this example:
+throughout the entire command. In other words, in this example:
    ENV abc=hello
    ENV abc=bye def=$abc
    ENV ghi=$abc
-will result in `def` having a value of `hello`, not `bye`.  However, 
+will result in `def` having a value of `hello`, not `bye`. However, 
 `ghi` will have a value of `bye` because it is not part of the same command
 that set `abc` to `bye`.
@@ -185,7 +187,7 @@ expansion) is done using Go's
 You can specify exceptions to exclusion rules. To do this, simply prefix a
 pattern with an `!` (exclamation mark) in the same way you would in a
-`.gitignore` file.  Currently there is no support for regular expressions.
+`.gitignore` file. Currently there is no support for regular expressions.
 Formats like `[^temp*]` are ignored. 
 The following is an example `.dockerignore` file:
@@ -245,7 +247,7 @@ Or
    FROM <image>@<digest>
-The `FROM` instruction sets the [*Base Image*](/terms/image/#base-image)
+The `FROM` instruction sets the [*Base Image*](/reference/glossary/#base-image)
 for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as
 its first instruction. The image can be any valid image – it is especially easy
 to start by **pulling an image** from the [*Public Repositories*](
@@ -304,7 +306,7 @@ commands using a base image that does not contain `/bin/sh`.
 The cache for `RUN` instructions isn't invalidated automatically during
 the next build. The cache for an instruction like 
-`RUN apt-get dist-upgrade -y` will be reused during the next build.  The 
+`RUN apt-get dist-upgrade -y` will be reused during the next build. The 
 cache for `RUN` instructions can be invalidated by using the `--no-cache` 
 flag, for example `docker build --no-cache`.
@@ -882,9 +884,9 @@ The `VOLUME` instruction creates a mount point with the specified name
 and marks it as holding externally mounted volumes from native host or other
 containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
 string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
-/var/db`.  For more information/examples and mounting instructions via the
+/var/db`. For more information/examples and mounting instructions via the
 Docker client, refer to 
-[*Share Directories via Volumes*](/userguide/dockervolumes/#volume)
+[*Share Directories via Volumes*](/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume)
 documentation.
 The `docker run` command initializes the newly created volume with any data 
@@ -900,6 +902,10 @@ This Dockerfile results in an image that causes `docker run`, to
 create a new mount point at `/myvol` and copy the  `greeting` file 
 into the newly created volume.
 > **Note**:
 > If any build steps change the data within the volume after it has been
 > declared, those changes will be discarded.
 > **Note**:
 > The list is parsed as a JSON array, which means that
 > you must use double-quotes (") around words not single-quotes (').
@@ -19,6 +19,10 @@ aufs (advanced multi layered unification filesystem) is a Linux [filesystem](#fi
 Docker supports as a storage backend. It implements the
 [union mount](http://en.wikipedia.org/wiki/Union_mount) for Linux file systems.
 ## Base image
 An image that has no parent is a **base image**.
 ## boot2docker
 [boot2docker](http://boot2docker.io/) is a lightweight Linux distribution made
@@ -25,8 +25,16 @@ driver sends the following metadata in the structured log message:
 | `container_name` | The container name at the time it was started. If you use `docker rename` to rename a container, the new name is not reflected in the journal entries.                                         |
 | `source`         | `stdout` or `stderr`                |
 The `docker logs` command is not available for this logging driver.
 ## Usage
 Some options are supported by specifying `--log-opt` as many times as needed:
 - `fluentd-address`: specify `host:port` to connect `localhost:24224`
 - `fluentd-tag`: specify tag for fluentd message, which interpret some markup, ex `{{.ID}}`, `{{.FullID}}` or `{{.Name}}` `docker.{{.ID}}`
 Configure the default logging driver by passing the
 `--log-driver` option to the Docker daemon:
@@ -1,129 +1,18 @@
 <!--[metadata]>
 +++
-title = "Configure logging drivers"
+title = "Logging Drivers"
-description = "Configure logging driver."
+description = "Logging Drivers"
-keywords = ["Fluentd, docker, logging, driver"]
+keywords = [" docker, logging, driver"]
 [menu.main]
-parent = "smn_logging"
+parent = "smn_administrate"
 identifier = "smn_logging"
 weight=8
 +++
 <![end-metadata]-->
-# Configure logging drivers
+# Logging Drivers
-The container can have a different logging driver than the Docker daemon. Use
+* [Configuring logging drivers](overview)
-the `--log-driver=VALUE` with the `docker run` command to configure the
+* [Fluentd logging driver](fluentd)
-container's logging driver. The following options are supported:
+* [Journald logging driver](journald)
 | `none`      | Disables any logging for the container. `docker logs` won't be available with this driver.                                    |
 |-------------|-------------------------------------------------------------------------------------------------------------------------------|
 | `json-file` | Default logging driver for Docker. Writes JSON messages to file.                                                              |
 | `syslog`    | Syslog logging driver for Docker. Writes log messages to syslog.                                                              |
 | `journald`  | Journald logging driver for Docker. Writes log messages to `journald`.                                                        |
 | `gelf`      | Graylog Extended Log Format (GELF) logging driver for Docker. Writes log messages to a GELF endpoint likeGraylog or Logstash. |
 | `fluentd`   | Fluentd logging driver for Docker. Writes log messages to `fluentd` (forward input).                                          |
 The `docker logs`command is available only for the `json-file` logging driver.  
 ### The json-file options
 The following logging options are supported for the `json-file` logging driver:
    --log-opt max-size=[0-9+][k|m|g]
    --log-opt max-file=[0-9+]
 Logs that reach `max-size` are rolled over. You can set the size in kilobytes(k), megabytes(m), or gigabytes(g). eg `--log-opt max-size=50m`. If `max-size` is not set, then logs are not rolled over.
 `max-file` specifies the maximum number of files that a log is rolled over before being discarded. eg `--log-opt max-file=100`. If `max-size` is not set, then `max-file` is not honored.
 If `max-size` and `max-file` are set, `docker logs` only returns the log lines from the newest log file. 
 ### The syslog options
 The following logging options are supported for the `syslog` logging driver:
    --log-opt syslog-address=[tcp|udp]://host:port
    --log-opt syslog-address=unix://path
    --log-opt syslog-facility=daemon
    --log-opt syslog-tag="mailer"
 `syslog-address` specifies the remote syslog server address where the driver connects to.
 If not specified it defaults to the local unix socket of the running system.
 If transport is either `tcp` or `udp` and `port` is not specified it defaults to `514`
 The following example shows how to have the `syslog` driver connect to a `syslog`
 remote server at `192.168.0.42` on port `123`
    $ docker run --log-driver=syslog --log-opt syslog-address=tcp://192.168.0.42:123
 The `syslog-facility` option configures the syslog facility. By default, the system uses the
 `daemon` value. To override this behavior, you can provide an integer of 0 to 23 or any of
 the following named facilities:
 * `kern`
 * `user`
 * `mail`
 * `daemon`
 * `auth`
 * `syslog`
 * `lpr`
 * `news`
 * `uucp`
 * `cron`
 * `authpriv`
 * `ftp`
 * `local0`
 * `local1`
 * `local2`
 * `local3`
 * `local4`
 * `local5`
 * `local6`
 * `local7`
 The `syslog-tag` specifies a tag that identifies the container's syslog messages. By default,
 the system uses the first 12 characters of the container id. To override this behavior, specify
 a `syslog-tag` option
 ## Specify journald options
 The `journald` logging driver stores the container id in the journal's `CONTAINER_ID` field. For detailed information on
 working with this logging driver, see [the journald logging driver](/reference/logging/journald/)
 reference documentation.
 ## Specify gelf options
 The GELF logging driver supports the following options:
    --log-opt gelf-address=udp://host:port
    --log-opt gelf-tag="database"
 The `gelf-address` option specifies the remote GELF server address that the
 driver connects to. Currently, only `udp` is supported as the transport and you must
 specify a `port` value. The following example shows how to connect the `gelf`
 driver to a GELF remote server at `192.168.0.42` on port `12201`
    $ docker run --log-driver=gelf --log-opt gelf-address=udp://192.168.0.42:12201
 The `gelf-tag` option specifies a tag for easy container identification.
 ## Specify fluentd options
 You can use the `--log-opt NAME=VALUE` flag to specify these additional Fluentd logging driver options.
 - `fluentd-address`: specify `host:port` to connect [localhost:24224]
 - `fluentd-tag`: specify tag for `fluentd` message, 
 When specifying a `fluentd-tag` value, you can use the following markup tags:
 - `{{.ID}}`: short container id (12 characters)
 - `{{.FullID}}`: full container id
 - `{{.Name}}`: container name
 For example, to specify both additional options:
 `docker run --log-driver=fluentd --log-opt fluentd-address=localhost:24224 --log-opt fluentd-tag=docker.{{.Name}}`
 If container cannot connect to the Fluentd daemon on the specified address,
 the container stops immediately. For detailed information on working with this
 logging driver, see [the fluentd logging driver](/reference/logging/fluentd/)
@@ -0,0 +1,130 @@
 <!--[metadata]>
 +++
 title = "Configuring Logging Drivers"
 description = "Configure logging driver."
 keywords = ["Fluentd, docker, logging, driver"]
 [menu.main]
 parent = "smn_logging"
 weight=-1
 +++
 <![end-metadata]-->
 # Configure logging drivers
 The container can have a different logging driver than the Docker daemon. Use
 the `--log-driver=VALUE` with the `docker run` command to configure the
 container's logging driver. The following options are supported:
 | `none`      | Disables any logging for the container. `docker logs` won't be available with this driver.                                    |
 |-------------|-------------------------------------------------------------------------------------------------------------------------------|
 | `json-file` | Default logging driver for Docker. Writes JSON messages to file.                                                              |
 | `syslog`    | Syslog logging driver for Docker. Writes log messages to syslog.                                                              |
 | `journald`  | Journald logging driver for Docker. Writes log messages to `journald`.                                                        |
 | `gelf`      | Graylog Extended Log Format (GELF) logging driver for Docker. Writes log messages to a GELF endpoint likeGraylog or Logstash. |
 | `fluentd`   | Fluentd logging driver for Docker. Writes log messages to `fluentd` (forward input).                                          |
 The `docker logs`command is available only for the `json-file` logging driver.  
 ### The json-file options
 The following logging options are supported for the `json-file` logging driver:
    --log-opt max-size=[0-9+][k|m|g]
    --log-opt max-file=[0-9+]
 Logs that reach `max-size` are rolled over. You can set the size in kilobytes(k), megabytes(m), or gigabytes(g). eg `--log-opt max-size=50m`. If `max-size` is not set, then logs are not rolled over.
 `max-file` specifies the maximum number of files that a log is rolled over before being discarded. eg `--log-opt max-file=100`. If `max-size` is not set, then `max-file` is not honored.
 If `max-size` and `max-file` are set, `docker logs` only returns the log lines from the newest log file. 
 ### The syslog options
 The following logging options are supported for the `syslog` logging driver:
    --log-opt syslog-address=[tcp|udp]://host:port
    --log-opt syslog-address=unix://path
    --log-opt syslog-facility=daemon
    --log-opt syslog-tag="mailer"
 `syslog-address` specifies the remote syslog server address where the driver connects to.
 If not specified it defaults to the local unix socket of the running system.
 If transport is either `tcp` or `udp` and `port` is not specified it defaults to `514`
 The following example shows how to have the `syslog` driver connect to a `syslog`
 remote server at `192.168.0.42` on port `123`
    $ docker run --log-driver=syslog --log-opt syslog-address=tcp://192.168.0.42:123
 The `syslog-facility` option configures the syslog facility. By default, the system uses the
 `daemon` value. To override this behavior, you can provide an integer of 0 to 23 or any of
 the following named facilities:
 * `kern`
 * `user`
 * `mail`
 * `daemon`
 * `auth`
 * `syslog`
 * `lpr`
 * `news`
 * `uucp`
 * `cron`
 * `authpriv`
 * `ftp`
 * `local0`
 * `local1`
 * `local2`
 * `local3`
 * `local4`
 * `local5`
 * `local6`
 * `local7`
 The `syslog-tag` specifies a tag that identifies the container's syslog messages. By default,
 the system uses the first 12 characters of the container id. To override this behavior, specify
 a `syslog-tag` option
 ## Specify journald options
 The `journald` logging driver stores the container id in the journal's `CONTAINER_ID` field. For detailed information on
 working with this logging driver, see [the journald logging driver](/reference/logging/journald/)
 reference documentation.
 ## Specify gelf options
 The GELF logging driver supports the following options:
    --log-opt gelf-address=udp://host:port
    --log-opt gelf-tag="database"
 The `gelf-address` option specifies the remote GELF server address that the
 driver connects to. Currently, only `udp` is supported as the transport and you must
 specify a `port` value. The following example shows how to connect the `gelf`
 driver to a GELF remote server at `192.168.0.42` on port `12201`
    $ docker run --log-driver=gelf --log-opt gelf-address=udp://192.168.0.42:12201
 The `gelf-tag` option specifies a tag for easy container identification.
 ## Specify fluentd options
 You can use the `--log-opt NAME=VALUE` flag to specify these additional Fluentd logging driver options.
 - `fluentd-address`: specify `host:port` to connect [localhost:24224]
 - `fluentd-tag`: specify tag for `fluentd` message, 
 When specifying a `fluentd-tag` value, you can use the following markup tags:
 - `{{.ID}}`: short container id (12 characters)
 - `{{.FullID}}`: full container id
 - `{{.Name}}`: container name
 For example, to specify both additional options:
 `docker run --log-driver=fluentd --log-opt fluentd-address=localhost:24224 --log-opt fluentd-tag=docker.{{.Name}}`
 If container cannot connect to the Fluentd daemon on the specified address,
 the container stops immediately. For detailed information on working with this
 logging driver, see [the fluentd logging driver](/reference/logging/fluentd/)
@@ -19,11 +19,11 @@ parent = "mn_reference"
 **Docker runs processes in isolated containers**. When an operator
 executes `docker run`, she starts a process with its own file system,
 its own networking, and its own isolated process tree.  The
-[*Image*](/terms/image/#image) which starts the process may define
+[*Image*](/reference/glossary/#image) which starts the process may define
 defaults related to the binary to run, the networking to expose, and
 more, but `docker run` gives final control to the operator who starts
 the container from the image. That's the main reason
-[*run*](/reference/commandline/cli/#run) has more options than any
+[*run*](/reference/commandline/run) has more options than any
 other `docker` command.
 ## General form
@@ -87,7 +87,7 @@ In detached mode (`-d=true` or just `-d`), all I/O should be done
 through network connections or shared volumes because the container is
 no longer listening to the command line where you executed `docker run`.
 You can reattach to a detached container with `docker`
-[*attach*](/reference/commandline/cli/#attach). If you choose to run a
+[*attach*](/reference/commandline/attach). If you choose to run a
 container in the detached mode, then you cannot use the `--rm` option.
 ### Foreground
@@ -360,8 +360,8 @@ Using the `--restart` flag on Docker run you can specify a restart policy for
 how a container should or should not be restarted on exit.
 When a restart policy is active on a container, it will be shown as either `Up`
-or `Restarting` in [`docker ps`](/reference/commandline/cli/#ps). It can also be
+or `Restarting` in [`docker ps`](/reference/commandline/ps). It can also be
-useful to use [`docker events`](/reference/commandline/cli/#events) to see the
+useful to use [`docker events`](/reference/commandline/events) to see the
 restart policy in effect.
 Docker supports the following restart policies:
@@ -417,7 +417,7 @@ You can specify the maximum amount of times Docker will try to restart the
 container when using the **on-failure** policy.  The default is that Docker
 will try forever to restart the container. The number of (attempted) restarts
 for a container can be obtained via [`docker inspect`](
-/reference/commandline/cli/#inspect). For example, to get the number of restarts
+/reference/commandline/inspect). For example, to get the number of restarts
 for container "my-container";
    $ docker inspect -f "{{ .RestartCount }}" my-container
@@ -491,9 +491,7 @@ command:
    $ docker run --security-opt label:type:svirt_apache_t -i -t centos bash
-Note:
+> **Note**: You would have to write policy defining a `svirt_apache_t` type.
 You would have to write policy defining a `svirt_apache_t` type.
 ## Specifying custom cgroups
@@ -507,16 +505,18 @@ parent group.
 The operator can also adjust the performance parameters of the
 container:
-    -m, --memory="": Memory limit (format: <number><optional unit>, where unit = b, k, m or g)
+| Option                     |  Description                                                                                |
-    --memory-swap="": Total memory limit (memory + swap, format: <number><optional unit>, where unit = b, k, m or g)
+|----------------------------|---------------------------------------------------------------------------------------------|
-    -c, --cpu-shares=0: CPU shares (relative weight)
+| `-m`, `--memory="" `       | Memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)                        |
-    --cpu-period=0: Limit the CPU CFS (Completely Fair Scheduler) period
+| `--memory-swap=""`         | Total memory limit (memory + swap, format: `<number>[<unit>]`, where unit = b, k, m or g)   |
-    --cpuset-cpus="": CPUs in which to allow execution (0-3, 0,1)
+| `-c`, `--cpu-shares=0`     | CPU shares (relative weight)                                                                |
-    --cpuset-mems="": Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+| `--cpu-period=0`           | Limit the CPU CFS (Completely Fair Scheduler) period                                        |
-    --cpu-quota=0: Limit the CPU CFS (Completely Fair Scheduler) quota
+| `--cpuset-cpus="" `        | CPUs in which to allow execution (0-3, 0,1)                                                 |
-    --blkio-weight=0: Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+| `--cpuset-mems=""`         | Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems. |
-    --oom-kill-disable=true|false: Whether to disable OOM Killer for the container or not.
+| `--cpu-quota=0`            | Limit the CPU CFS (Completely Fair Scheduler) quota                                         |
-    --memory-swappiness="": Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
+| `--blkio-weight=0`         | Block IO weight (relative weight) accepts a weight value between 10 and 1000.               |
 | `--oom-kill-disable=false` | Whether to disable OOM Killer for the container or not.                                     |
 | `--memory-swappiness=""  ` | Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.        |
 ### Memory constraints
@@ -568,7 +568,7 @@ We have four ways to set memory usage:
  </tbody>
 </table>
-Examples:
+### Examples
    $ docker run -ti ubuntu:14.04 /bin/bash
@@ -600,8 +600,6 @@ Only disable the OOM killer on containers where you have also set the
 running out of memory and require killing the host's system processes to free
 memory.
 Examples:
 The following example limits the memory to 100M and disables the OOM killer for
 this container:
@@ -894,7 +892,7 @@ familiar with using LXC directly.
 > you can use `--lxc-conf` to set a container's IP address, but this will not be
 > reflected in the `/etc/hosts` file.
-# Logging drivers (--log-driver)
+## Logging drivers (--log-driver)
 The container can have a different logging driver than the Docker daemon. Use
 the `--log-driver=VALUE` with the `docker run` command to configure the
@@ -910,17 +908,8 @@ container's logging driver. The following options are supported:
 	The `docker logs`command is available only for the `json-file` logging
 driver.  For detailed information on working with logging drivers, see
-[Configure a logging driver](reference/logging/).
+[Configure a logging driver](/reference/logging/overview/).
 #### Logging driver: fluentd
 Fluentd logging driver for Docker. Writes log messages to fluentd (forward input). `docker logs`
 command is not available for this logging driver.
 Some options are supported by specifying `--log-opt` as many as needed, like `--log-opt fluentd-address=localhost:24224 --log-opt fluentd-tag=docker.{{.Name}}`.
 - `fluentd-address`: specify `host:port` to connect [localhost:24224]
 - `fluentd-tag`: specify tag for fluentd message, which interpret some markup, ex `{{.ID}}`, `{{.FullID}}` or `{{.Name}}` [docker.{{.ID}}]
 ## Overriding Dockerfile image defaults
@@ -942,7 +931,7 @@ Dockerfile instruction and how the operator can override that setting.
 - [USER](#user)
 - [WORKDIR](#workdir)
-## CMD (default command or options)
+### CMD (default command or options)
 Recall the optional `COMMAND` in the Docker
 commandline:
@@ -958,7 +947,7 @@ image), you can override that `CMD` instruction just by specifying a new
 If the image also specifies an `ENTRYPOINT` then the `CMD` or `COMMAND`
 get appended as arguments to the `ENTRYPOINT`.
-## ENTRYPOINT (default command to execute at runtime)
+### ENTRYPOINT (default command to execute at runtime)
    --entrypoint="": Overwrite the default entrypoint set by the image
@@ -981,7 +970,7 @@ or two examples of how to pass more parameters to that ENTRYPOINT:
    $ docker run -i -t --entrypoint /bin/bash example/redis -c ls -l
    $ docker run -i -t --entrypoint /usr/bin/redis-cli example/redis --help
-## EXPOSE (incoming ports)
+### EXPOSE (incoming ports)
 The Dockerfile doesn't give much control over networking, only providing
 the `EXPOSE` instruction to give a hint to the operator about what
@@ -1023,7 +1012,7 @@ then the client container can access the exposed port via a private
 networking interface.  Docker will set some environment variables in the
 client container to help indicate which interface and port to use.
-## ENV (environment variables)
+### ENV (environment variables)
 When a new container is created, Docker will set the following environment
 variables automatically:
@@ -1059,7 +1048,7 @@ variables automatically:
 The container may also include environment variables defined
 as a result of the container being linked with another container. See
-the [*Container Links*](/userguide/dockerlinks/#container-linking)
+the [*Container Links*](/userguide/dockerlinks/#connect-with-the-linking-system)
 section for more details.
 Additionally, the operator can **set any environment variable** in the
@@ -1136,7 +1125,7 @@ container's `/etc/hosts` entry will be automatically updated.
 > restarted. We recommend using the host entries in `/etc/hosts` to resolve the
 > IP address of linked containers.
-## VOLUME (shared filesystems)
+### VOLUME (shared filesystems)
    -v=[]: Create a bind mount with: [host-dir:]container-dir[:rw|ro].
           If 'host-dir' is missing, then docker creates a new volume.
@@ -1151,18 +1140,21 @@ one or more `VOLUME`'s associated with an image, but only the operator
 can give access from one container to another (or from a container to a
 volume mounted on the host).
-## USER
+### USER
-The default user within a container is `root` (id = 0), but if the
+`root` (id = 0) is the default user within a container. The image developer can
-developer created additional users, those are accessible too. The
+create additional users. Those users are accessible by name.  When passing a numeric
-developer can set a default user to run the first process with the
+ID, the user does not have to exist in the container.
-Dockerfile `USER` instruction, but the operator can override it:
+
 The developer can set a default user to run the first process with the
 Dockerfile `USER` instruction. When starting a container, the operator can override
 the `USER` instruction by passing the `-u` option.
    -u="": Username or UID
-> **Note:** if you pass numeric uid, it must be in range 0-2147483647.
+> **Note:** if you pass a numeric uid, it must be in the range of 0-2147483647.
-## WORKDIR
+### WORKDIR
 The default working directory for running binaries within a container is the
 root directory (`/`), but the developer can set a different default with the
@@ -32,7 +32,7 @@ $  export DOCKER_CONTENT_TRUST_TAGGING_PASSPHRASE="l7pEQcTKJjUHm6Lpe4"
 Then, when pushing a new tag the Docker client does not request these values but signs automatically:
-``bash
+```bash
 $  docker push docker/trusttest:latest
 The push refers to a repository [docker.io/docker/trusttest] (len: 1)
 a9539b34a6ab: Image already exists
@@ -45,7 +45,7 @@ Signing and pushing trust metadata
 You can also build with content trust. Before running the `docker build` command, you should set the environment variable `DOCKER_CONTENT_TRUST` either manually or in in a scripted fashion. Consider the simple Dockerfile below. 
-```Dockerfilea
+```Dockerfile
 FROM docker/trusttest:latest
 RUN echo
 ```
@@ -45,8 +45,7 @@ The Docker client stores the keys in the `~/.docker/trust/private` directory.
 Before backing them up, you should `tar` them into an archive:
 ```bash
-$ tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
+$ umask 077; tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private; umask 022
 $ chmod 600 private_keys_backup.tar.gz
 ```
 ## Lost keys
@@ -15,7 +15,7 @@ The sandbox allows you to configure and try trust operations locally without
 impacting your production images. 
 Before working through this sandbox, you should have read through the [trust
-overview](content_trust.md).
+overview](/security/trust/content_trust).
 ### Prerequisites
@@ -25,8 +25,8 @@ have `sudo` privileges on your local machine or in the VM.
 This sandbox requires you to install two Docker tools: Docker Engine and Docker
 Compose. To install the Docker Engine, choose from the [list of supported
-platforms]({{< relref "installation.md" >}}). To install Docker Compose, see the
+platforms](/installation). To install Docker Compose, see the
-[detailed instructions here]({{< relref "compose/install" >}}).
+[detailed instructions here](/compose/install).
 Finally, you'll need to have `git` installed on your local system or VM.
@@ -1,51 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Container"
 description = "Definitions of a container"
 keywords = ["containers, lxc, concepts, explanation, image,  container"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # Container
 ## Introduction
 ![](/terms/images/docker-filesystems-busyboxrw.png)
 Once you start a process in Docker from an [*Image*](/terms/image), Docker
 fetches the image and its [*Parent Image*](/terms/image), and repeats the
 process until it reaches the [*Base Image*](/terms/image/#base-image-def). Then
 the [*Union File System*](/terms/layer) adds a read-write layer on top. That
 read-write layer, plus the information about its [*Parent
 Image*](/terms/image)
 and some additional information like its unique id, networking
 configuration, and resource limits is called a **container**.
 ## Container state
 Containers can change, and so they have state. A container may be
 **running** or **exited**.
 When a container is running, the idea of a "container" also includes a
 tree of processes running on the CPU, isolated from the other processes
 running on the host.
 When the container is exited, the state of the file system and its exit
 value is preserved. You can start, stop, and restart a container. The
 processes restart from scratch (their memory state is **not** preserved
 in a container), but the file system is just as it was when the
 container was stopped.
 You can promote a container to an [*Image*](/terms/image) with `docker commit`.
 Once a container is an image, you can use it as a parent for new containers.
 ## Container IDs
 All containers are identified by a 64 hexadecimal digit string
 (internally a 256bit value). To simplify their use, a short ID of the
 first 12 characters can be used on the command line. There is a small
 possibility of short id collisions, so the docker server will always
 return the long ID.
@@ -1,42 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "File system"
 description = "How Linux organizes its persistent storage"
 keywords = ["containers, files,  linux"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # File system
 ## Introduction
 ![](/terms/images/docker-filesystems-generic.png)
 In order for a Linux system to run, it typically needs two [file
 systems](http://en.wikipedia.org/wiki/Filesystem):
 1. boot file system (bootfs)
 2. root file system (rootfs)
 The **boot file system** contains the bootloader and the kernel. The
 user never makes any changes to the boot file system. In fact, soon
 after the boot process is complete, the entire kernel is in memory, and
 the boot file system is unmounted to free up the RAM associated with the
 initrd disk image.
 The **root file system** includes the typical directory structure we
 associate with Unix-like operating systems:
 `/dev, /proc, /bin, /etc, /lib, /usr,` and `/tmp` plus all the configuration
 files, binaries and libraries required to run user applications (like bash,
 ls, and so forth).
 While there can be important kernel differences between different Linux
 distributions, the contents and organization of the root file system are
 usually what make your software packages dependent on one distribution
 versus another. Docker can help solve this problem by running multiple
 distributions at the same time.
 ![](/terms/images/docker-filesystems-multiroot.png)
@@ -1,47 +0,0 @@
 <!--[metadata]>
 +++
 draft = true 
 title = "Image"
 description = "Definition of an image"
 keywords = ["containers, lxc, concepts, explanation, image,  container"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # Image
 ## Introduction
 ![](/terms/images/docker-filesystems-debian.png)
 In Docker terminology, a read-only [*Layer*](/terms/layer/#layer) is
 called an **image**. An image never changes.
 Since Docker uses a [*Union File System*](/terms/layer/#union-file-system), the
 processes think the whole file system is mounted read-write. But all the
 changes go to the top-most writeable layer, and underneath, the original
 file in the read-only image is unchanged. Since images don't change,
 images do not have state.
 ![](/terms/images/docker-filesystems-debianrw.png)
 ## Parent image
 ![](/terms/images/docker-filesystems-multilayer.png)
 Each image may depend on one more image which forms the layer beneath
 it. We sometimes say that the lower image is the **parent** of the upper
 image.
 ## Base image
 An image that has no parent is a **base image**.
 ## Image IDs
 All images are identified by a 64 hexadecimal digit string (internally a
 256bit value). To simplify their use, a short ID of the first 12
 characters can be used on the command line. There is a small possibility
 of short id collisions, so the docker server will always return the long
 ID.
@@ -1,42 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Layers"
 description = "Organizing the Docker Root File System"
 keywords = ["containers, lxc, concepts, explanation, image,  container"]
 [menu.main]
 parent = "mn_use_docker"
 +++
 <![end-metadata]-->
 # Layers
 ## Introduction
 In a traditional Linux boot, the kernel first mounts the root [*File
 System*](/terms/filesystem) as read-only, checks its
 integrity, and then switches the whole rootfs volume to read-write mode.
 ## Layer
 When Docker mounts the rootfs, it starts read-only, as in a traditional
 Linux boot, but then, instead of changing the file system to read-write
 mode, it takes advantage of a [union
 mount](http://en.wikipedia.org/wiki/Union_mount) to add a read-write
 file system *over* the read-only file system. In fact there may be
 multiple read-only file systems stacked on top of each other. We think
 of each one of these file systems as a **layer**.
 ![](/terms/images/docker-filesystems-multilayer.png)
 At first, the top read-write layer has nothing in it, but any time a
 process creates a file, this happens in the top layer. And if something
 needs to update an existing file in a lower layer, then the file gets
 copied to the upper layer and changes go into the copy. The version of
 the file on the lower layer cannot be seen by the applications anymore,
 but it is there, unchanged.
 ## Union File System
 We call the union of the read-write layer and all the read-only layers a
 **union file system**.
@@ -1,27 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Registry"
 description = "Definition of an Registry"
 keywords = ["containers, concepts, explanation, image, repository,  container"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # Registry
 ## Introduction
 A Registry is a hosted service containing
 [*repositories*](/terms/repository/#repository-def) of
 [*images*](/terms/image/#image-def) which responds to the Registry API.
 The default registry can be accessed using a browser at
 [Docker Hub](https://hub.docker.com) or using the
 `docker search` command.
 ## Further reading
 For more information see [*Working with
 Repositories*](/userguide/dockerrepos/#working-with-the-repository)
@@ -1,42 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Repository"
 description = "Definition of an Repository"
 keywords = ["containers, concepts, explanation, image, repository,  container"]
 [menu.main]
 parent = "identifier"
 +++
 <![end-metadata]-->
 # Repository
 ## Introduction
 A repository is a set of images either on your local Docker server, or
 shared, by pushing it to a [*Registry*](/terms/registry/#registry-def)
 server.
 Images can be associated with a repository (or multiple) by giving them
 an image name using one of three different commands:
 1. At build time (e.g., `docker build -t IMAGENAME`),
 2. When committing a container (e.g.,
   `docker commit CONTAINERID IMAGENAME`) or
 3. When tagging an image id with an image name (e.g.,
   `docker tag IMAGEID IMAGENAME`).
 A Fully Qualified Image Name (FQIN) can be made up of 3 parts:
 `[registry_hostname[:port]/][user_name/](repository_name:version_tag)`
 `username` and `registry_hostname` default to an empty string. When
 `registry_hostname` is an empty string, then `docker push` will push to
 `index.docker.io:80`.
 If you create a new repository which you want to share, you will need to
 set at least the `user_name`, as the `default` blank `user_name` prefix is
 reserved for [Official Repositories](/docker-hub/official_repos).
 For more information see [*Working with
 Repositories*](/userguide/dockerrepos/#working-with-the-repository)
@@ -1,78 +0,0 @@
 <!--[metadata]>
 +++
 title = "Getting started with Docker Hub"
 description = "Introductory guide to getting an account on Docker Hub"
 keywords = ["documentation, docs, the docker guide, docker guide, docker, docker platform, virtualization framework, docker.io, central service, services, how to, container, containers, automation, collaboration, collaborators, registry, repo, repository, technology, github webhooks,  trusted builds"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 1
 +++
 <![end-metadata]-->
 # Getting started with Docker Hub
 This section provides a quick introduction to the [Docker Hub](https://hub.docker.com),
 including how to create an account.
 The [Docker Hub](https://hub.docker.com) is a centralized resource for working with
 Docker and its components. Docker Hub helps you collaborate with colleagues and get the
 most out of Docker. To do this, it provides services such as:
 * Docker image hosting.
 * User authentication.
 * Automated image builds and work-flow tools such as build triggers and web
  hooks.
 * Integration with GitHub and Bitbucket.
 In order to use Docker Hub, you will first need to register and create an account. Don't
 worry, creating an account is simple and free.
 ## Creating a Docker Hub account
 There are two ways for you to register and create an account:
 1. Via the web, or
 2. Via the command line.
 ### Register via the web
 Fill in the [sign-up form](https://hub.docker.com/account/signup/) by
 choosing your user name and password and entering a valid email address. You can also
 sign up for the Docker Weekly mailing list, which has lots of information about what's
 going on in the world of Docker.
 ![Register using the sign-up page](/userguide/register-web.png)
 ### Register via the command line
 You can also create a Docker Hub account via the command line with the
 `docker login` command.
    $ docker login
 ### Confirm your email
 Once you've filled in the form, check your email for a welcome message asking for
 confirmation so we can activate your account.
 ### Login
 After you complete the confirmation process, you can login using the web console:
 ![Login using the web console](/userguide/login-web.png)
 Or via the command line with the `docker login` command:
    $ docker login
 Your Docker Hub account is now active and ready to use.
 ##  Next steps
 Next, let's start learning how to Dockerize applications with our "Hello world"
 exercise.
 Go to [Dockerizing Applications](/userguide/dockerizing).
@@ -133,8 +133,8 @@ This really long string is called a *container ID*. It uniquely
 identifies a container so we can work with it.
 > **Note:** 
-> The container ID is a bit long and unwieldy and a bit later
+> The container ID is a bit long and unwieldy. A bit later,
-> on we'll see a shorter ID and some ways to name our containers to make
+> we'll see a shorter ID and ways to name our containers to make
 > working with them easier.
 We can use this container ID to see what's happening with our `hello world` daemon.
@@ -157,8 +157,8 @@ is running, its status and an automatically assigned name,
 `insane_babbage`. 
 > **Note:** 
-> Docker automatically names any containers you start, a
+> Docker automatically generates names for any containers started.
-> little later on we'll see how you can specify your own names.
+> We'll see how to specify your own names a bit later.
 Okay, so we now know it's running. But is it doing what we asked it to do? To see this
 we're going to look inside the container using the `docker logs`
@@ -227,11 +227,11 @@ The components in this prefix are:
 Docker uses this prefix format to define three distinct environment variables:
 * The `prefix_ADDR` variable contains the IP Address from the URL, for
-example `WEBDB_PORT_8080_TCP_ADDR=172.17.0.82`.
+example `WEBDB_PORT_5432_TCP_ADDR=172.17.0.82`.
 * The `prefix_PORT` variable contains just the port number from the URL for
-example `WEBDB_PORT_8080_TCP_PORT=8080`.
+example `WEBDB_PORT_5432_TCP_PORT=5432`.
 * The `prefix_PROTO` variable contains just the protocol from the URL for
-example `WEBDB_PORT_8080_TCP_PROTO=tcp`.
+example `WEBDB_PORT_5432_TCP_PROTO=tcp`.
 If the container exposes multiple ports, an environment variable set is
 defined for each one. This means, for example, if a container exposes 4 ports
@@ -240,7 +240,7 @@ that Docker creates 12 environment variables, 3 for each port.
 Additionally, Docker creates an environment variable called `<alias>_PORT`.
 This variable contains the URL of the source container's first exposed port.
 The  'first' port is defined as the exposed port with the lowest number.
-For example, consider the `WEBDB_PORT=tcp://172.17.0.82:8080` variable.  If
+For example, consider the `WEBDB_PORT=tcp://172.17.0.82:5432` variable.  If
 that port is used for both tcp and udp, then the tcp one is specified.
 Finally, Docker also exposes each Docker originated environment variable
@@ -82,8 +82,7 @@ You now have an image from which you can run containers.
 Anyone can pull public images from the [Docker Hub](https://hub.docker.com)
 registry, but if you would like to share your own images, then you must
-register first, as we saw in the [first section of the Docker User
+[register first](/docker-hub/accounts).
 Guide](/userguide/dockerhub/).
 ## Pushing a repository to Docker Hub
@@ -28,7 +28,7 @@ Docker.
 A *data volume* is a specially-designated directory within one or more
 containers that bypasses the [*Union File
-System*](/terms/layer/#union-file-system). Data volumes provide several 
+System*](/reference/glossary#union-file-system). Data volumes provide several 
 useful features for persistent or shared data:
 - Volumes are initialized when a container is created. If the container's
@@ -74,16 +74,21 @@ The output will provide details on the container configurations including the
 volumes. The output should look something similar to the following:
    ...
-    "Volumes": {
+    Mounts": [
-        "/webapp": "/var/lib/docker/volumes/fac362...80535"
+        {
-    },
+            "Name": "fac362...80535",
-    "VolumesRW": {
+            "Source": "/var/lib/docker/volumes/fac362...80535/_data",
-        "/webapp": true
+            "Destination": "/webapp",
-    }
+            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ]
    ...
-You will notice in the above 'Volumes' is specifying the location on the host and 
+You will notice in the above 'Source' is specifying the location on the host and 
-'VolumesRW' is specifying that the volume is read/write.
+'Destination' is specifying the volume location inside the container. `RW` shows
 if the volume is read/write.
 ### Mount a host directory as a data volume
@@ -33,7 +33,7 @@ Docker Hub is the central hub for Docker. It hosts public Docker images
 and provides services to help you build and manage your Docker
 environment. To learn more:
-Go to [Using Docker Hub](/userguide/dockerhub).
+Go to [Using Docker Hub](/docker-hub).
 ## Dockerizing applications: A "Hello world"
@@ -11,11 +11,11 @@ parent="smn_containers"
 # Working with containers
 In the [last section of the Docker User Guide](/userguide/dockerizing)
-we launched our first containers. We launched two containers using the
+we launched our first containers. We launched containers using the
-`docker run` command.
+`docker run` command:
-* Containers we ran interactively in the foreground.
+* Interactive container runs in the foreground.
-* One container we ran daemonized in the background.
+* Daemonized container runs in the background.
 In the process we learned about several Docker commands:
@@ -43,17 +43,22 @@ version information on the currently installed Docker client and daemon.
 This command will not only provide you the version of Docker client and
 daemon you are using, but also the version of Go (the programming
 language powering Docker).
    Client:
      Version:      1.8.1
      API version:  1.20
      Go version:   go1.4.2
      Git commit:   d12ea79
      Built:        Thu Aug 13 02:35:49 UTC 2015
      OS/Arch:      linux/amd64
-    Client version: 0.8.0
+    Server:
-    Go version (client): go1.2
+      Version:      1.8.1
-
+      API version:  1.20
-    Git commit (client): cc3a8c8
+      Go version:   go1.4.2
-    Server version: 0.8.0
+      Git commit:   d12ea79
-
+      Built:        Thu Aug 13 02:35:49 UTC 2015
-    Git commit (server): cc3a8c8
+      OS/Arch:      linux/amd64
    Go version (server): go1.2
    Last stable version: 0.8.0
 ## Get Docker command help
@@ -105,7 +110,7 @@ Lastly, we've specified a command for our container to run: `python app.py`. Thi
 > **Note:** 
 > You can see more detail on the `docker run` command in the [command
-> reference](/reference/commandline/cli/#run) and the [Docker Run
+> reference](/reference/commandline/run) and the [Docker Run
 > Reference](/reference/run/).
 ## Viewing our web application container
@@ -219,8 +224,8 @@ the container.
 ## Inspecting our web application container
 Lastly, we can take a low-level dive into our Docker container using the
-`docker inspect` command. It returns a JSON hash of useful configuration
+`docker inspect` command. It returns a JSON document containing useful
-and status information about Docker containers.
+configuration and status information for the specified container.
    $ docker inspect nostalgic_morse
@@ -297,7 +302,7 @@ this again by stopping the container first.
 And now our container is stopped and deleted.
 > **Note:**
-> Always remember that deleting a container is final!
+> Always remember that removing a container is final!
 # Next steps
@@ -29,12 +29,13 @@ func (s *TagStore) NewPusher(endpoint registry.APIEndpoint, localRepo Repository
 	switch endpoint.Version {
 	case registry.APIVersion2:
 		return &v2Pusher{
-			TagStore:  s,
+			TagStore:   s,
-			endpoint:  endpoint,
+			endpoint:   endpoint,
-			localRepo: localRepo,
+			localRepo:  localRepo,
-			repoInfo:  repoInfo,
+			repoInfo:   repoInfo,
-			config:    imagePushConfig,
+			config:     imagePushConfig,
-			sf:        sf,
+			sf:         sf,
 			layersSeen: make(map[string]bool),
 		}, nil
 	case registry.APIVersion1:
 		return &v1Pusher{
@@ -27,6 +27,11 @@ type v2Pusher struct {
 	config    *ImagePushConfig
 	sf        *streamformatter.StreamFormatter
 	repo      distribution.Repository
 	// layersSeen is the set of layers known to exist on the remote side.
 	// This avoids redundant queries when pushing multiple tags that
 	// involve the same layers.
 	layersSeen map[string]bool
 }
 func (p *v2Pusher) Push() (fallback bool, err error) {
@@ -87,8 +92,6 @@ func (p *v2Pusher) pushV2Tag(tag string) error {
 		return fmt.Errorf("tag does not exist: %s", tag)
 	}
 	layersSeen := make(map[string]bool)
 	layer, err := p.graph.Get(layerId)
 	if err != nil {
 		return err
@@ -117,7 +120,7 @@ func (p *v2Pusher) pushV2Tag(tag string) error {
 			return err
 		}
-		if layersSeen[layer.ID] {
+		if p.layersSeen[layer.ID] {
 			break
 		}
@@ -172,7 +175,7 @@ func (p *v2Pusher) pushV2Tag(tag string) error {
 		m.FSLayers = append(m.FSLayers, manifest.FSLayer{BlobSum: dgst})
 		m.History = append(m.History, manifest.History{V1Compatibility: string(jsonData)})
-		layersSeen[layer.ID] = true
+		p.layersSeen[layer.ID] = true
 	}
 	logrus.Infof("Signed manifest for %s:%s using daemon's key: %s", p.repo.Name(), tag, p.trustKey.KeyID())
@@ -60,40 +60,31 @@ func (s *DockerRegistrySuite) TestPushMultipleTags(c *check.C) {
 	dockerCmd(c, "tag", "busybox", repoTag2)
-	dockerCmd(c, "push", repoName)
+	out, _ := dockerCmd(c, "push", repoName)
-	// Ensure layer list is equivalent for repoTag1 and repoTag2
+	// There should be no duplicate hashes in the output
-	out1, _ := dockerCmd(c, "pull", repoTag1)
+	imageSuccessfullyPushed := ": Image successfully pushed"
 	if strings.Contains(out1, "Tag t1 not found") {
 		c.Fatalf("Unable to pull pushed image: %s", out1)
 	}
 	imageAlreadyExists := ": Image already exists"
-	var out1Lines []string
+	imagePushHashes := make(map[string]struct{})
-	for _, outputLine := range strings.Split(out1, "\n") {
+	outputLines := strings.Split(out, "\n")
-		if strings.Contains(outputLine, imageAlreadyExists) {
+	for _, outputLine := range outputLines {
-			out1Lines = append(out1Lines, outputLine)
+		if strings.Contains(outputLine, imageSuccessfullyPushed) {
 			hash := strings.TrimSuffix(outputLine, imageSuccessfullyPushed)
 			if _, present := imagePushHashes[hash]; present {
 				c.Fatalf("Duplicate image push: %s", outputLine)
 			}
 			imagePushHashes[hash] = struct{}{}
 		} else if strings.Contains(outputLine, imageAlreadyExists) {
 			hash := strings.TrimSuffix(outputLine, imageAlreadyExists)
 			if _, present := imagePushHashes[hash]; present {
 				c.Fatalf("Duplicate image push: %s", outputLine)
 			}
 			imagePushHashes[hash] = struct{}{}
 		}
 	}
-	out2, _ := dockerCmd(c, "pull", repoTag2)
+	if len(imagePushHashes) == 0 {
-	if strings.Contains(out2, "Tag t2 not found") {
+		c.Fatal(`Expected at least one line containing "Image successfully pushed"`)
 		c.Fatalf("Unable to pull pushed image: %s", out1)
 	}
 	var out2Lines []string
 	for _, outputLine := range strings.Split(out2, "\n") {
 		if strings.Contains(outputLine, imageAlreadyExists) {
 			out1Lines = append(out1Lines, outputLine)
 		}
 	}
 	if len(out1Lines) != len(out2Lines) {
 		c.Fatalf("Mismatched output length:\n%s\n%s", out1, out2)
 	}
 	for i := range out1Lines {
 		if out1Lines[i] != out2Lines[i] {
 			c.Fatalf("Mismatched output line:\n%s\n%s", out1Lines[i], out2Lines[i])
 		}
 	}
 }
@@ -38,10 +38,7 @@ static void	log_with_errno_init()
 */
 import "C"
-import (
+import "unsafe"
 	"reflect"
 	"unsafe"
 )
 type (
 	CDmTask C.struct_dm_task
@@ -187,21 +184,12 @@ func dmTaskGetDepsFct(task *CDmTask) *Deps {
 	if Cdeps == nil {
 		return nil
 	}
 	// golang issue: https://github.com/golang/go/issues/11925
 	hdr := reflect.SliceHeader{
 		Data: uintptr(unsafe.Pointer(uintptr(unsafe.Pointer(Cdeps)) + unsafe.Sizeof(*Cdeps))),
 		Len:  int(Cdeps.count),
 		Cap:  int(Cdeps.count),
 	}
 	devices := *(*[]C.uint64_t)(unsafe.Pointer(&hdr))
 	deps := &Deps{
 		Count:  uint32(Cdeps.count),
 		Filler: uint32(Cdeps.filler),
 	}
-	for _, device := range devices {
+	for _, device := range Cdeps.device {
-		deps.Device = append(deps.Device, uint64(device))
+		deps.Device = append(deps.Device, (uint64)(device))
 	}
 	return deps
 }
@@ -4,7 +4,6 @@ import (
 	"bytes"
 	"errors"
 	"io/ioutil"
 	"os"
 )
 var (
@@ -13,22 +12,12 @@ var (
 	// file to check to determine Operating System
 	etcOsRelease = "/etc/os-release"
 	// used by stateless systems like Clear Linux
 	altEtcOSRelease = "/usr/lib/os-release"
 )
 func GetOperatingSystem() (string, error) {
 	b, err := ioutil.ReadFile(etcOsRelease)
 	if err != nil {
-		if _, err2 := os.Stat(altEtcOSRelease); err2 == nil {
+		return "", err
 			b, err2 = ioutil.ReadFile(altEtcOSRelease)
 			if err2 != nil {
 				return "", err2
 			}
 		} else {
 			return "", err
 		}
 	}
 	if i := bytes.Index(b, []byte("PRETTY_NAME")); i >= 0 {
 		b = b[i+13:]
@@ -89,7 +89,6 @@ type bridgeNetwork struct {
 	config     *networkConfiguration
 	endpoints  map[types.UUID]*bridgeEndpoint // key: endpoint id
 	portMapper *portmapper.PortMapper
 	veth       *netlink.Veth
 	sync.Mutex
 }
@@ -895,13 +894,11 @@ func (d *driver) CreateEndpoint(nid, eid types.UUID, epInfo driverapi.EndpointIn
 		return err
 	}
 	logrus.Warnf("network %v", n)
 	logrus.Warnf("veth %v", n.veth)
 	// Generate and add the interface pipe host <-> sandbox
-	n.veth = &netlink.Veth{
+	veth := &netlink.Veth{
 		LinkAttrs: netlink.LinkAttrs{Name: hostIfName, TxQLen: 0},
 		PeerName:  containerIfName}
-	if err = netlink.LinkAdd(n.veth); err != nil {
+	if err = netlink.LinkAdd(veth); err != nil {
 		return err
 	}
@@ -1166,11 +1163,6 @@ func (d *driver) EndpointOperInfo(nid, eid types.UUID) (map[string]interface{},
 		m[netlabel.MacAddress] = ep.macAddress
 	}
 	// Add details of the bridge
 	m[netlabel.BridgeName] = n.config.BridgeName
 	m[netlabel.BridgePeername] = n.veth.PeerName
 	m[netlabel.BridgeLinkName] = n.veth.LinkAttrs.Name
 	return m, nil
 }
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
moxiegirl	942363d3ca	Merge pull request #15701 from moxiegirl/819-publish-cherrypicks 819 publish cherrypicks	2015-08-19 13:41:37 -07:00
Tonis Tiigi	44f2104028	Update volumes userguide Fixes #15644 Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com> (cherry picked from commit `cc2aab7816`)	2015-08-19 10:07:50 -07:00
Philipp Wahala	6117b05e87	Small fix in dev env docs Signed-off-by: Philipp Wahala <philipp.wahala@gmail.com> (cherry picked from commit `fbc0ea32e8`) Conflicts: docs/project/set-up-dev-env.md	2015-08-19 10:07:39 -07:00
Qiang Huang	7d7ef1188b	Add format description in run doc And only set false to --oom-kill-disable, we just need the default value to show. Signed-off-by: Qiang Huang <h.huangqiang@huawei.com> (cherry picked from commit `2a468ed7e4`)	2015-08-19 10:06:47 -07:00
Morgan Bauer	c6d31c934b	remove references to 'source repository' - rewrite intro to Dockerfile reference usage section to remove references to 'source repository' - Closes #14714 - Fixes: #8648 - Updating with Seb's comments Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `b143c05d64`)	2015-08-19 10:06:38 -07:00
Sebastiaan van Stijn	8df037b7ca	docs: fix anchor link on Ubuntu installation page Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit `5dd28c1f9d`)	2015-08-19 10:06:33 -07:00
Mary Anthony	72b8e7e3ac	Updating hashcode links to commands Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `85c2c77188`)	2015-08-19 10:06:27 -07:00
Kai Blin	f9f2dbcb15	reference/run: Clarify the use of numeric UIDs it is possible to pass an UID that has not been created inside the container, clarify this in the docs. This should fix issue #14795 Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `a7cfb098d4`) Conflicts: docs/reference/run.md	2015-08-19 10:06:09 -07:00
Kai Blin	3d18cd851b	reference/run: Add a paragraph break Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `4d89910820`) Conflicts: docs/reference/run.md	2015-08-19 10:04:24 -07:00
Kai Blin	7324d8dd8c	reference/run: Add some articles Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `8a61e2b151`) Conflicts: docs/reference/run.md	2015-08-19 10:02:17 -07:00
Kai Blin	a3ae93dc2e	reference/run: Some editorial changes Based on the suggestions from @moxiegirl, some changes to make the wording more clear. Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `ba29d31c9c`) Conflicts: docs/reference/run.md	2015-08-19 10:00:26 -07:00
Patrick Hemmer	385676735b	add documentation clarifying behavior of VOLUME instruction Signed-off-by: Patrick Hemmer <patrick.hemmer@gmail.com> (cherry picked from commit `08a867b82f`)	2015-08-19 09:58:36 -07:00
Dharmit Shah	3e2e0397f3	Fixing docs to remove references to links under terms/ Removed terms/ directory Signed-off-by: Dharmit Shah <shahdharmit@gmail.com> (cherry picked from commit `0a925d07a8`)	2015-08-19 09:58:16 -07:00
Michael Grauer	512f486e0c	Update dev machine name to default in mac installation docs Signed-off-by: Michael Grauer <michael.grauer@kitware.com> (cherry picked from commit `f26045a534`)	2015-08-19 09:58:10 -07:00
Charles Chan	745722293d	Cleanup "Working with containers" page. * Cleanup introduction * Update output of `docker version` * Cleanup explaination of `docker inspect` * Change 'deleting' to 'removing' for consistency Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com> (cherry picked from commit `2fcae333e8`)	2015-08-19 09:58:00 -07:00
Charles Chan	87f58529b2	Reformat /containers/(id)/resize to make it consistent with "Exec Resize" section. Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com> (cherry picked from commit `6cd2d89469`) Conflicts: docs/reference/api/docker_remote_api_v1.21.md	2015-08-19 09:57:39 -07:00
Charles Chan	8f7cdbb060	Improve/fix "Dockerizing Applications" page. * Try to update the wording for the notes. Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com> (cherry picked from commit `316eb2979e`)	2015-08-19 09:53:09 -07:00
Morgan Bauer	172c412ae8	fix link Signed-off-by: Morgan Bauer <mbauer@us.ibm.com> (cherry picked from commit `c50e78e799`)	2015-08-19 09:53:04 -07:00
Diogo Monica	67baebe9e7	Fixing race condition on private key backup how-to Signed-off-by: Diogo Monica <diogo@docker.com> (cherry picked from commit `fbb268c12a`)	2015-08-19 09:52:59 -07:00
moxiegirl	e1eee1290d	Fixing bad formatting reported by David via email Fixed and tested Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `ef453f7118`)	2015-08-19 09:52:40 -07:00
bin liu	d3fe81f9ba	fix broken link to glossary page. Signed-off-by: bin liu <liubin0329@gmail.com> (cherry picked from commit `f6753cd963`)	2015-08-19 09:52:23 -07:00
Sebastiaan van Stijn	551c4559ad	docs: fix fedora prerequisites heading Fixes the prerequisites heading not being rendered properly, because of a missing space. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit `2c18e1cd05`)	2015-08-19 09:52:16 -07:00
bin liu	2eaa994b24	change port number through example context Signed-off-by: bin liu <liubin0329@gmail.com> (cherry picked from commit `b0a65f93a5`)	2015-08-19 09:52:06 -07:00
moxiegirl	e9183b35a3	Merge pull request #15514 from moxiegirl/fix-installation-images Docker Toolbox Updates fixes #14561	2015-08-11 23:39:41 -07:00
Mary Anthony	19c08cd7f4	Docker Toolbox Updates fixes #14561 - Tested Mac/iterated with Jeff on fixes - Waiting on formal uninstall;manual now - 4 hour work - Fixe #14562 converting Windows to Mac - Found errors in installer need fixes/another iteration - Updated as far as possible with limited installation - 3 Hours work - Entering comments from PR review - New screen captures and migration material - Entering Sven's comment - Testing with powershell, Seb's comments - Fix link in upgrade - Minor tweaks to http and typos - Adding deprecation note Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `6ca22add18`) Conflicts: docs/installation/mac.md docs/installation/windows.md	2015-08-11 23:31:06 -07:00
moxiegirl	e6d84bddc4	Merge pull request #15513 from moxiegirl/pull-link-fixes Fixes after release	2015-08-11 23:18:56 -07:00
Mary Anthony	f5ab4142be	Fixes after release Adding in a link about the deprecated material Fixing bad link to staging Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `8b09f8a302`)	2015-08-11 23:16:16 -07:00
moxiegirl	7d71532829	Merge pull request #15499 from moxiegirl/fix-hub-cp Removal of docker-hub	2015-08-11 15:23:51 -07:00
Sven Dowideit	da5014009c	Removing Hub v1 documentation, Hub v2 documentation will come from that repository Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (cherry picked from commit `70092b3ee0`)	2015-08-11 15:21:37 -07:00
Sven Dowideit	3a2e6b3871	remove unused images Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (cherry picked from commit `9f530aba7f`)	2015-08-11 15:21:25 -07:00
moxiegirl	e041a26365	Merge pull request #15490 from moxiegirl/cp-logging-change Several fixes in formatting	2015-08-11 11:58:58 -07:00
Mary Anthony	b7960c1e45	Several fixes in formatting - fixing headings in run.md - creating a table for readability - adding index for logging - moving logging overview into logging - Updating with Seb's comments Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `70aa63b92a`)	2015-08-11 11:57:54 -07:00