merge the newest version

.editorconfig

@@ -0,0 +1,11 @@
+# EditorConfig is awesome: http://EditorConfig.org
+
+# top-most EditorConfig file
+root = true
+
+# Unix-style newlines with a newline ending every file
+[*]
+end_of_line = lf
+insert_final_newline = true
+indent_size = 4
+indent_style = tab

CONTRIBUTING.md

@@ -2,4 +2,6 @@ Hey, thanks for wanting to contribute to baseimage-docker. :)
 
 If you have a question, please use the [discussion forum](https://groups.google.com/d/forum/passenger-docker). The Github issue tracker is only for **bug reports and feature requests**.
 
-If you want to develop baseimage-docker, use the Vagrantfile in the repository. It will setup an Ubuntu VM with Docker installed in it. Use the Makefile to build the image.
+If you want to develop baseimage-docker, use the Vagrantfile in the repository. It will setup an Ubuntu VM with Docker installed in it. Use the Makefile to build the Docker image.
+
+All development happens on the `next` branch. The `master` branch is supposed to point to the latest stable release, because users read documentation from the `master` branch.

Changelog.md

@@ -1,3 +1,13 @@
+## 0.9.16 (release date: 2015-01-20)
+
+ * `docker exec` is now the default and recommended mechanism for running commands in the container. SSH is now disabled by default, but is still supported for those cases where "docker exec" is not appropriate. Closes GH-168.
+ * All syslog output is now forwarded to `docker logs`. Closes GH-123.
+ * The workaround for Docker bug 2267 (the inability to modify /etc/hosts) has been removed, because it has been fixed upstream. Closes GH-155.
+ * Logrotate now reloads syslog-ng properly. Closes GH-167.
+ * Fixed some locale issues. Closes GH-178. Thanks to David J. M. Karlsen.
+ * Fixed problems with cron. Closes GH-115.
+ * Contribution by Bryan Bishop.
+
 ## 0.9.15 (release date: 2014-10-03)
 
  * Fixed the setuid bit on /usr/bin/sudo. This problem was caused by Docker bug #6828.

Makefile

@@ -1,5 +1,5 @@
 NAME = phusion/baseimage
-VERSION = 0.9.15
+VERSION = 0.9.16
 
 .PHONY: all build test tag_latest release ssh
 
@@ -12,7 +12,7 @@ test:
 	env NAME=$(NAME) VERSION=$(VERSION) ./test/runner.sh
 
 tag_latest:
-	docker tag $(NAME):$(VERSION) $(NAME):latest
+	docker tag -f $(NAME):$(VERSION) $(NAME):latest
 
 release: test tag_latest
 	@if ! docker images $(NAME) | awk '{ print $$2 }' | grep -q -F $(VERSION); then echo "$(NAME) version $(VERSION) is not yet built. Please run 'make build'"; false; fi

README.md

@@ -1,14 +1,14 @@
 # A minimal Ubuntu base image modified for Docker-friendliness
 
-Baseimage-docker is a special [Docker](http://www.docker.io) image that is configured for correct use within Docker containers. It is Ubuntu, plus:
+Baseimage-docker is a special [Docker](https://www.docker.com) image that is configured for correct use within Docker containers. It is Ubuntu, plus:
 
  * Modifications for Docker-friendliness.
- * Workarounds for [some Docker bugs](#workaroud_modifying_etc_hosts).
+ * Administration tools that are especially useful in the context of Docker.
- * Useful administration tools.
+ * Mechanisms for easily running multiple processes, [without violating the Docker philosophy](#docker_single_process).
 
 You can use it as a base for your own Docker images.
 
-Baseimage-docker is available for pulling from [the Docker registry](https://index.docker.io/u/phusion/baseimage/)!
+Baseimage-docker is available for pulling from [the Docker registry](https://registry.hub.docker.com/u/phusion/baseimage/)!
 
 ### What are the problems with the stock Ubuntu base image?
 
@@ -52,15 +52,14 @@ You can configure the stock `ubuntu` image yourself from your Dockerfile, so why
      * [Environment variable dumps](#envvar_dumps)
      * [Modifying environment variables](#modifying_envvars)
      * [Security](#envvar_security)
-   * [Working around Docker's inability to modify /etc/hosts](#workaroud_modifying_etc_hosts)
-   * [Disabling SSH](#disabling_ssh)
  * [Container administration](#container_administration)
    * [Running a one-shot command in a new container](#oneshot)
    * [Running a command in an existing, running container](#run_inside_existing_container)
-   * [Login to the container via nsenter](#login_nsenter)
+   * [Login to the container via `docker exec`](#login_docker_exec)
-     * [Usage](#nsenter_usage)
+     * [Usage](#docker_exec)
-     * [The `docker-bash` tool](#docker_bash)
    * [Login to the container via SSH](#login_ssh)
+     * [Enabling SSH](#enabling_ssh)
+     * [About SSH keys](#ssh_keys)
      * [Using the insecure key for one container only](#using_the_insecure_key_for_one_container_only)
      * [Enabling the insecure key permanently](#enabling_the_insecure_key_permanently)
      * [Using your own key](#using_your_own_key)
@@ -81,12 +80,11 @@ You can configure the stock `ubuntu` image yourself from your Dockerfile, so why
 | Component        | Why is it included? / Remarks |
 | ---------------- | ------------------- |
 | Ubuntu 14.04 LTS | The base system. |
-| A **correct** init process | According to the Unix process model, [the init process](https://en.wikipedia.org/wiki/Init) -- PID 1 -- inherits all [orphaned child processes](https://en.wikipedia.org/wiki/Orphan_process) and must [reap them](https://en.wikipedia.org/wiki/Wait_(system_call)). Most Docker containers do not have an init process that does this correctly, and as a result their containers become filled with [zombie processes](https://en.wikipedia.org/wiki/Zombie_process) over time. <br><br>Furthermore, `docker stop` sends SIGTERM to the init process, which is then supposed to stop all services. Unfortunately most init systems don't do this correctly within Docker since they're built for hardware shutdowns instead. This causes processes to be hard killed with SIGKILL, which doesn't give them a chance to correctly deinitialize things. This can cause file corruption. <br><br>Baseimage-docker comes with an init process `/sbin/my_init` that performs both of these tasks correctly. |
+| A **correct** init process | _Main article: [Docker and the PID 1 zombie reaping problem](http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/)._ <br><br>According to the Unix process model, [the init process](https://en.wikipedia.org/wiki/Init) -- PID 1 -- inherits all [orphaned child processes](https://en.wikipedia.org/wiki/Orphan_process) and must [reap them](https://en.wikipedia.org/wiki/Wait_(system_call)). Most Docker containers do not have an init process that does this correctly, and as a result their containers become filled with [zombie processes](https://en.wikipedia.org/wiki/Zombie_process) over time. <br><br>Furthermore, `docker stop` sends SIGTERM to the init process, which is then supposed to stop all services. Unfortunately most init systems don't do this correctly within Docker since they're built for hardware shutdowns instead. This causes processes to be hard killed with SIGKILL, which doesn't give them a chance to correctly deinitialize things. This can cause file corruption. <br><br>Baseimage-docker comes with an init process `/sbin/my_init` that performs both of these tasks correctly. |
 | Fixes APT incompatibilities with Docker | See https://github.com/dotcloud/docker/issues/1024. |
-| Workarounds for Docker bugs | [Learn more.](#workaroud_modifying_etc_hosts) |
+| syslog-ng | A syslog daemon is necessary so that many services - including the kernel itself - can correctly log to /var/log/syslog. If no syslog daemon is running, a lot of important messages are silently swallowed. <br><br>Only listens locally. All syslog messages are forwarded to "docker logs". |
-| syslog-ng | A syslog daemon is necessary so that many services - including the kernel itself - can correctly log to /var/log/syslog. If no syslog daemon is running, a lot of important messages are silently swallowed. <br><br>Only listens locally. |
 | logrotate | Rotates and compresses logs on a regular basis. |
-| SSH server | Allows you to easily login to your container to [inspect or administer](#login_ssh) things. <br><br>_SSH is only one of the methods provided by baseimage-docker for this purpose. The other method is through [the nsenter tool](#login_nsenter). SSH is also provided as an option because nsenter has many issues._<br><br>Password and challenge-response authentication are disabled by default. Only key authentication is allowed.<br><br>SSH access can be easily disabled if you so wish. Read on for instructions. |
+| SSH server | Allows you to easily login to your container to [inspect or administer](#login_ssh) things. <br><br>_SSH is **disabled by default** and is only one of the methods provided by baseimage-docker for this purpose. The other method is through [docker exec](#login_docker_exec). SSH is also provided as an alternative because `docker exec` comes with several caveats._<br><br>Password and challenge-response authentication are disabled by default. Only key authentication is allowed. |
 | cron | The cron daemon must be running for cron jobs to work. |
 | [runit](http://smarden.org/runit/) | Replaces Ubuntu's Upstart. Used for service supervision and management. Much easier to use than SysV init and supports restarting daemons when they crash. Much easier to use and more lightweight than Upstart. |
 | `setuser` | A tool for running a command as another user. Easier to use than `su`, has a smaller attack vector than `sudo`, and unlike `chpst` this tool sets `$HOME` correctly. Available as `/sbin/setuser`. |
@@ -98,7 +96,7 @@ Baseimage-docker is very lightweight: it only consumes 6 MB of memory.
 
 The Docker developers advocate the philosophy of running a single *logical service* per container. A logical service can consist of multiple OS processes.
 
-Baseimage-docker only advocates running multiple OS processes inside a single container. We believe this makes sense because at the very least it would solve [the PID 1 problem](#whats_inside_overview) and the "syslog blackhole" problem. By running multiple processes, we solve very real Unix OS-level problems, with minimal overhead and without turning the container into multiple logical services.
+Baseimage-docker only advocates running multiple OS processes inside a single container. We believe this makes sense because at the very least it would solve [the PID 1 problem](http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/) and the "syslog blackhole" problem. By running multiple processes, we solve very real Unix OS-level problems, with minimal overhead and without turning the container into multiple logical services.
 
 Splitting your logical service into multiple OS processes also makes sense from a security standpoint. By running processes as different users, you can limit the impact of vulnerabilities. Baseimage-docker provides tools to encourage running processes as different users, e.g. the `setuser` tool.
 
@@ -109,7 +107,7 @@ Do we advocate running multiple *logical services* in a single container? Not ne
 
 There are people who are under the impression that Baseimage-docker advocates treating containers as VMs, because of the fact that Baseimage-docker advocates the use of multiple processes. Therefore they are also under the impression that Baseimage-docker does not follow the Docker philosophy. Neither of these impressions are true.
 
-The Docker developers advocate running multiple *logical services* inside a single container. But we are not disputing that. Baseimage-docker advocates running multiple *OS processes* inside a single container, and a single logical service can consist of multiple OS processes.
+The Docker developers advocate running a single *logical service* inside a single container. But we are not disputing that. Baseimage-docker advocates running multiple *OS processes* inside a single container, and a single logical service can consist of multiple OS processes.
 
 It follows from this that Baseimage-docker also does not deny the Docker philosophy. In fact, many of the modifications we introduce are explicitly in line with the Docker philosophy. For example, using environment variables to pass parameters to containers is very much the "Docker way", and provide [a mechanism to easily work with environment variables](#environment_variables) in the presence of multiple processes that may run as different users.
 
@@ -138,14 +136,6 @@ The image is called `phusion/baseimage`, and is available on the Docker registry
     # a list of version numbers.
     FROM phusion/baseimage:<VERSION>
     
-    # Set correct environment variables.
-    ENV HOME /root
-    
-    # Regenerate SSH host keys. baseimage-docker does not contain any, so you
-    # have to do that yourself. You may also comment out this instruction; the
-    # init system will auto-generate one during boot.
-    RUN /etc/my_init.d/00_regen_ssh_host_keys.sh
-    
     # Use baseimage-docker's init system.
     CMD ["/sbin/my_init"]
     
@@ -163,13 +153,15 @@ The shell script must be called `run`, must be executable, and is to be placed i
 
 Here's an example showing you how a memcached server runit entry can be made.
 
-    ### In memcached.sh (make sure this file is chmod +x):
+In `memcached.sh` (make sure this file is chmod +x):
+
     #!/bin/sh
     # `/sbin/setuser memcache` runs the given command as the user `memcache`.
     # If you omit that part, the command will be run as root.
     exec /sbin/setuser memcache /usr/bin/memcached >>/var/log/memcached.log 2>&1
 
-    ### In Dockerfile:
+In `Dockerfile`:
+
     RUN mkdir /etc/service/memcached
     ADD memcached.sh /etc/service/memcached/run
 
@@ -187,11 +179,13 @@ All scripts must exit correctly, e.g. with exit code 0. If any script exits with
 
 The following example shows how you can add a startup script. This script simply logs the time of boot to the file /tmp/boottime.txt.
 
-    ### In logtime.sh (make sure this file is chmod +x):
+In `logtime.sh` (make sure this file is chmod +x):
+    
     #!/bin/sh
     date > /tmp/boottime.txt
 
-    ### In Dockerfile:
+In `Dockerfile`:
+
     RUN mkdir -p /etc/my_init.d
     ADD logtime.sh /etc/my_init.d/logtime.sh
 
@@ -280,34 +274,6 @@ If you are sure that your environment variables don't contain sensitive data, th
     RUN chmod 755 /etc/container_environment
     RUN chmod 644 /etc/container_environment.sh /etc/container_environment.json
 
-<a name="workaroud_modifying_etc_hosts"></a>
-### Working around Docker's inability to modify /etc/hosts
-
-It is currently not possible to modify /etc/hosts inside a Docker container because of [Docker bug 2267](https://github.com/dotcloud/docker/issues/2267). Baseimage-docker includes a workaround for this. You have to be explicitly opt-in for the workaround.
-
-The workaround involves modifying a system library, libnss_files.so.2, so that it looks for the host file in /etc/workaround-docker-2267/hosts instead of /etc/hosts. Instead of modifying /etc/hosts, you modify /etc/workaround-docker-2267/hosts instead.
-
-Add this to your Dockerfile to opt-in for the workaround. This command modifies libnss_files.so.2 as described above.
-
-    RUN /usr/bin/workaround-docker-2267
-
-(You don't necessarily have to run this command from the Dockerfile. You can also run it from a shell inside the container.)
-
-To verify that it works, [open a bash shell in your container](#inspecting), modify /etc/workaround-docker-2267/hosts, and check whether it had any effect:
-
-    bash# echo 127.0.0.1 my-test-domain.com >> /etc/workaround-docker-2267/hosts
-    bash# ping my-test-domain.com
-    ...should ping 127.0.0.1...
-
-**Note on apt-get upgrading:** if any Ubuntu updates overwrite libnss_files.so.2, then the workaround is removed. You have to re-enable it by running `/usr/bin/workaround-docker-2267`. To be safe, you should run this command every time after running `apt-get upgrade`.
-
-<a name="disabling_ssh"></a>
-### Disabling SSH
-
-Baseimage-docker enables an SSH server by default, so that you can [use SSH](#login_ssh) to [administer your container](#container_administration). In case you do not want to enable SSH, here's how you can disable it:
-
-    RUN rm -rf /etc/service/sshd /etc/my_init.d/00_regen_ssh_host_keys.sh
-
 <a name="container_administration"></a>
 ## Container administration
 
@@ -338,11 +304,6 @@ This will perform the following:
 For example:
 
     $ docker run phusion/baseimage:<VERSION> /sbin/my_init -- ls
-    *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
-    No SSH host key available. Generating one...
-    Creating SSH2 RSA key; this may take some time ...
-    Creating SSH2 DSA key; this may take some time ...
-    Creating SSH2 ECDSA key; this may take some time ...
     *** Running /etc/rc.local...
     *** Booting runit daemon...
     *** Runit started as PID 80
@@ -364,15 +325,15 @@ The following example runs `ls` without running the startup files and with less
 
 There are two ways to run a command inside an existing, running container.
 
- * Through the `nsenter` tool. This tool uses Linux kernel system calls in order to execute a command within the context of a container. Learn more in [Login to the container, or running a command inside it, via nsenter](#login_nsenter).
+ * Through the `docker exec` tool. This is builtin Docker tool, available since Docker 1.4. Internally, it uses Linux kernel system calls in order to execute a command within the context of a container. Learn more in [Login to the container, or running a command inside it, via `docker exec`](#login_docker_exec).
  * Through SSH. This approach requires running an SSH daemon inside the container, and requires you to setup SSH keys. Learn more in [Login to the container, or running a command inside it, via SSH](#login_ssh).
 
 Both way have their own pros and cons, which you can learn in their respective subsections.
 
-<a name="login_nsenter"></a>
+<a name="login_docker_exec"></a>
-### Login to the container, or running a command inside it, via nsenter
+### Login to the container, or running a command inside it, via `docker exec`
 
-You can use the `nsenter` tool on the Docker host OS to login to any container that is based on baseimage-docker. You can also use it to run a command inside a running container. `nsenter` works by using Linux kernel system calls.
+You can use the `docker exec` tool on the Docker host OS to login to any container that is based on baseimage-docker. You can also use it to run a command inside a running container. `docker exec` works by using Linux kernel system calls.
 
 Here's how it compares to [using SSH to login to the container or to run a command inside it](#login_ssh):
 
@@ -381,19 +342,14 @@ Here's how it compares to [using SSH to login to the container or to run a comma
    * Does not require setting up SSH keys.
    * Works on any container, even containers not based on baseimage-docker.
  * Cons
-   * Processes executed by `nsenter` behave in a slightly different manner than normal. For example, they cannot be killed by any normal processes inside the container. This applies to all child processes as well.
+   * If the `docker exec` process on the host is terminated by a signal (e.g. with the `kill` command or even with Ctrl-C), then the command that is executed by `docker exec` is *not* killed and cleaned up. You will either have to do that manually, or you have to run `docker exec` with `-t -i`.
-   * If the `nsenter` process is terminated by a signal (e.g. with the `kill` command), then the command that is executed by nsenter is *not* killed and cleaned up. You will have to do that manually. (Note that terminal control commands like Ctrl-C *do* clean up all child processes, because terminal signals are sent to all processes in the terminal session.)
+   * Requires privileges on the Docker host to be able to access the Docker daemon. Note that anybody who can access the Docker daemon effectively has root access.
-   * Requires learning another tool.
-   * Requires root privileges on the Docker host.
-   * Requires the `nsenter` tool to be available on the Docker host. At the time of writing (July 2014), most Linux distributions do not ship it. However, baseimage-docker provides a precompiled binary, and allows you to easily use it, through its [docker-bash](#docker_bash) tool.
    * Not possible to allow users to login to the container without also letting them login to the Docker host.
 
-<a name="nsenter_usage"></a>
+<a name="docker_exec_usage"></a>
 #### Usage
 
-First, ensure that `nsenter` is installed. At the time of writing (July 2014), almost no Linux distribution ships the `nsenter` tool. However, we provide [a precompiled binary](#docker_bash) that anybody can use.
+Start a container:
-
-Anyway, start a container:
 
     docker run YOUR_IMAGE
 
@@ -401,57 +357,43 @@ Find out the ID of the container that you just ran:
 
     docker ps
 
-Once you have the ID, look for the PID of the main process inside the container.
+Now that you have the ID, you can use `docker exec` to run arbitrary commands in the container. For example, to run `echo hello world`:
 
-    docker inspect -f "{{ .State.Pid }}" <ID>
+    docker exec YOUR-CONTAINER-ID echo hello world
 
-Now that you have the container's main process PID, you can use `nsenter` to login to the container, or to execute a command inside it:
+To open a bash session inside the container, you must pass `-t -i` so that a terminal is available:
 
-    # Login to the container
+    docker exec -t -i YOUR-CONTAINER-ID bash -l
-    nsenter --target <MAIN PROCESS PID> --mount --uts --ipc --net --pid bash -l
-
-    # Running a command inside the container
-    nsenter --target <MAIN PROCESS PID> --mount --uts --ipc --net --pid -- echo hello world
-
-<a name="docker_bash"></a>
-#### The `docker-bash` tool
-
-Looking up the main process PID of a container and typing the long nsenter command quickly becomes tedious. Luckily, we provide the `docker-bash` tool which automates this process. This tool is to be run on the *Docker host*, not inside a Docker container.
-
-This tool also comes with a precompiled `nsenter` binary, so that you don't have to install `nsenter` yourself. `docker-bash` works out-of-the-box!
-
-First, install the tool on the Docker host:
-
-    curl --fail -L -O https://github.com/phusion/baseimage-docker/archive/master.tar.gz && \
-    tar xzf master.tar.gz && \
-    sudo ./baseimage-docker-master/install-tools.sh
-
-Then run the tool as follows to login to a container:
-
-    docker-bash YOUR-CONTAINER-ID
-
-You can lookup `YOUR-CONTAINER-ID` by running `docker ps`.
-
-By default, `docker-bash` will open a Bash session. You can also tell it to run a command, and then exit:
-
-    docker-bash YOUR-CONTAINER-ID echo hello world
 
 <a name="login_ssh"></a>
 ### Login to the container, or running a command inside it, via SSH
 
 You can use SSH to login to any container that is based on baseimage-docker. You can also use it to run a command inside a running container.
 
-Here's how it compares to [using nsenter to login to the container or to run a command inside it](#login_nsenter):
+Here's how it compares to [using `docker exec` to login to the container or to run a command inside it](#login_docker_exec):
 
  * Pros
-   * Does not require a tool like `nsenter` to be available on the Docker host. Virtually everybody already has an SSH client installed.
-   * There no surprises with processes behaving slightly differently than normal, as is the case when using `nsenter`.
    * Does not require root privileges on the Docker host.
    * Allows you to let users login to the container, without letting them login to the Docker host. However, this is not enabled by default because baseimage-docker does not expose the SSH server to the public Internet by default.
  * Cons
    * Requires setting up SSH keys. However, baseimage-docker makes this easy for many cases through a pregenerated, insecure key. Read on to learn more.
 
-The first thing that you need to do is to ensure that you have the right SSH keys installed inside the container. By default, no keys are installed, so you can't login. For convenience reasons, we provide [a pregenerated, insecure key](https://github.com/phusion/baseimage-docker/blob/master/image/insecure_key) [(PuTTY format)](https://github.com/phusion/baseimage-docker/blob/master/image/insecure_key.ppk) that you can easily enable. However, please be aware that using this key is for convenience only. It does not provide any security because this key (both the public and the private side) is publicly available. **In production environments, you should use your own keys**.
+<a name="enabling_ssh"></a>
+#### Enabling SSH
+
+Baseimage-docker disables the SSH server by default. Add the following to your Dockerfile to enable it:
+
+    RUN rm -f /etc/service/sshd/down
+    
+    # Regenerate SSH host keys. baseimage-docker does not contain any, so you
+    # have to do that yourself. You may also comment out this instruction; the
+    # init system will auto-generate one during boot.
+    RUN /etc/my_init.d/00_regen_ssh_host_keys.sh
+
+<a name="ssh_keys"></a>
+#### About SSH keys
+
+First, you must ensure that you have the right SSH keys installed inside the container. By default, no keys are installed, so nobody can login. For convenience reasons, we provide [a pregenerated, insecure key](https://github.com/phusion/baseimage-docker/blob/master/image/insecure_key) [(PuTTY format)](https://github.com/phusion/baseimage-docker/blob/master/image/insecure_key.ppk) that you can easily enable. However, please be aware that using this key is for convenience only. It does not provide any security because this key (both the public and the private side) is publicly available. **In production environments, you should use your own keys**.
 
 <a name="using_the_insecure_key_for_one_container_only"></a>
 #### Using the insecure key for one container only
@@ -485,7 +427,7 @@ Now that you have the IP address, you can use SSH to login to the container, or
 <a name="enabling_the_insecure_key_permanently"></a>
 #### Enabling the insecure key permanently
 
-It is also possible to enable the insecure key in the image permanently. This is not generally recommended, but it suitable for e.g. temporary development or demo environments where security does not matter.
+It is also possible to enable the insecure key in the image permanently. This is not generally recommended, but is suitable for e.g. temporary development or demo environments where security does not matter.
 
 Edit your Dockerfile to install the insecure key permanently:
 

README_ZH_cn_.md

@@ -14,6 +14,8 @@ Baseimage-docker项目可以直接从Docker的[registry](https://index.docker.io
 <a name="what-are-the-problems-with-the-stock-ubuntu-base-image"></a>
 ### 原生的Ubuntu基础镜像有什么问题呢？          
             
+Baseimage-docker可以直接从[Docker registry](https://registry.hub.docker.com/u/phusion/baseimage/)获取！
+        
 原生Ubuntu不是为了在Docker内运行而设计的。它的初始化系统Upstart，假定运行的环境要么是真实的硬件，要么是虚拟的硬件，而不是在Docker容器内。但是在一个Docker的容器内，并不需要一个完整的系统，你需要的只是一个很小的系统。但是如果你不是非常熟悉Unix的系统模型，想要在Docker容器内裁减出最小的系统，会碰到很多难以正确解决的陌生的技术坑。这些坑会引起很多莫名其妙的问题。
 
 Baseimage-docker让这一切完美。在"内容"部分描述了所有这些修改。

image/00_regen_ssh_host_keys.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 set -e
-if [[ ! -e /etc/ssh/ssh_host_rsa_key ]]; then
+if [[ ! -e /etc/service/sshd/down && ! -e /etc/ssh/ssh_host_rsa_key ]] || [[ "$1" == "-f" ]]; then
 	echo "No SSH host key available. Generating one..."
 	export LC_ALL=C
 	export DEBIAN_FRONTEND=noninteractive

image/Dockerfile

@@ -2,7 +2,6 @@ FROM ubuntu:14.04
 MAINTAINER Phusion <info@phusion.nl>
 
 ENV HOME /root
-RUN mkdir /build
 ADD . /build
 
 RUN /build/prepare.sh && \

image/bin/my_init

@@ -56,9 +56,6 @@ def is_exe(path):
 	except OSError:
 		return False
 
-def create_hosts_file():
-	run_command_killable("/bin/cp", "/etc/hosts", "/etc/workaround-docker-2267/")
-
 def import_envvars(clear_existing_environment = True, override_existing_environment = True):
 	new_env = {}
 	for envfile in listdir("/etc/container_environment"):
@@ -252,7 +249,6 @@ def install_insecure_key():
 	run_command_killable("/usr/sbin/enable_insecure_key")
 
 def main(args):
-	create_hosts_file()
 	import_envvars(False, False)
 	export_envvars()
 

image/bin/workaround-docker-2267

@@ -1,2 +0,0 @@
-#!/bin/sh
-exec /usr/bin/perl -pi -e 's:/etc/hosts:/cte/hosts:g' /lib/x86_64-linux-gnu/libnss_files.so.2

image/config/logrotate_syslogng

@@ -0,0 +1,38 @@
+/var/log/syslog
+{
+	rotate 7
+	daily
+	missingok
+	notifempty
+	delaycompress
+	compress
+	postrotate
+		sv reload syslog-ng > /dev/null
+	endscript
+}
+
+/var/log/mail.info
+/var/log/mail.warn
+/var/log/mail.err
+/var/log/mail.log
+/var/log/daemon.log
+/var/log/kern.log
+/var/log/auth.log
+/var/log/user.log
+/var/log/lpr.log
+/var/log/cron.log
+/var/log/debug
+/var/log/messages
+{
+	rotate 4
+	weekly
+	missingok
+	notifempty
+	compress
+	delaycompress
+	sharedscripts
+	postrotate
+		sv reload syslog-ng > /dev/null
+		sv restart cron-log-forwarder > /dev/null
+	endscript
+}

image/prepare.sh

@@ -4,7 +4,9 @@ source /build/buildconfig
 set -x
 
 ## Temporarily disable dpkg fsync to make building faster.
-echo force-unsafe-io > /etc/dpkg/dpkg.cfg.d/02apt-speedup
+if [[ ! -e /etc/dpkg/dpkg.cfg.d/docker-apt-speedup ]]; then
+	echo force-unsafe-io > /etc/dpkg/dpkg.cfg.d/docker-apt-speedup
+fi
 
 ## Prevent initramfs updates from trying to run grub and lilo.
 ## https://journal.paul.querna.org/articles/2013/10/15/docker-ubuntu-on-rackspace/
@@ -30,12 +32,6 @@ ln -sf /bin/true /sbin/initctl
 dpkg-divert --local --rename --add /usr/bin/ischroot
 ln -sf /bin/true /usr/bin/ischroot
 
-## Workaround https://github.com/dotcloud/docker/issues/2267,
-## not being able to modify /etc/hosts.
-mkdir -p /etc/workaround-docker-2267
-ln -s /etc/workaround-docker-2267 /cte
-cp /build/bin/workaround-docker-2267 /usr/bin/
-
 ## Install HTTPS support for APT.
 $minimal_apt_get_install apt-transport-https ca-certificates
 
@@ -48,3 +44,6 @@ apt-get dist-upgrade -y --no-install-recommends
 ## Fix locale.
 $minimal_apt_get_install language-pack-en
 locale-gen en_US
+update-locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8
+echo -n en_US.UTF-8 > /etc/container_environment/LANG
+echo -n en_US.UTF-8 > /etc/container_environment/LC_CTYPE

image/runit/syslog-forwarder

@@ -0,0 +1,2 @@
+#!/bin/sh
+exec tail -F -n 0 /var/log/syslog

image/system_services.sh

@@ -25,17 +25,25 @@ mkdir /etc/service/syslog-ng
 cp /build/runit/syslog-ng /etc/service/syslog-ng/run
 mkdir -p /var/lib/syslog-ng
 cp /build/config/syslog_ng_default /etc/default/syslog-ng
+touch /var/log/syslog
+chmod u=rw,g=r,o= /var/log/syslog
 # Replace the system() source because inside Docker we
 # can't access /proc/kmsg.
 sed -i -E 's/^(\s*)system\(\);/\1unix-stream("\/dev\/log");/' /etc/syslog-ng/syslog-ng.conf
 
+## Install syslog to "docker logs" forwarder.
+mkdir /etc/service/syslog-forwarder
+cp /build/runit/syslog-forwarder /etc/service/syslog-forwarder/run
+
 ## Install logrotate.
 $minimal_apt_get_install logrotate
+cp /build/config/logrotate_syslogng /etc/logrotate.d/syslog-ng
 
 ## Install the SSH server.
 $minimal_apt_get_install openssh-server
 mkdir /var/run/sshd
 mkdir /etc/service/sshd
+touch /etc/service/sshd/down
 cp /build/runit/sshd /etc/service/sshd/run
 cp /build/config/sshd_config /etc/ssh/sshd_config
 cp /build/00_regen_ssh_host_keys.sh /etc/my_init.d/
@@ -53,6 +61,7 @@ cp /build/bin/enable_insecure_key /usr/sbin/
 ## Install cron daemon.
 $minimal_apt_get_install cron
 mkdir /etc/service/cron
+chmod 600 /etc/crontab
 cp /build/runit/cron /etc/service/cron/run
 
 ## Remove useless cron entries.

test/runner.sh

@@ -28,8 +28,15 @@ fi
 
 trap cleanup EXIT
 
+echo " --> Enabling SSH in the container"
+docker exec -t -i $ID /etc/my_init.d/00_regen_ssh_host_keys.sh -f
+docker exec -t -i $ID rm /etc/service/sshd/down
+docker exec -t -i $ID sv start /etc/service/sshd
+sleep 1
+
 echo " --> Logging into container and running tests"
-chmod 600 image/insecure_key
+cp image/insecure_key /tmp/insecure_key
+chmod 600 /tmp/insecure_key
 sleep 1 # Give container some more time to start up.
-ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i image/insecure_key root@$IP \
+ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i /tmp/insecure_key root@$IP \
 	/bin/bash /test/test.sh