Incrementing version

This reverts commit 34408d8013, reversing
changes made to 5d80f284b0.

.travis.yml

@@ -0,0 +1,7 @@
+sudo: required
+
+services:
+  - docker
+  
+script:
+  - make build

Makefile

@@ -1,5 +1,5 @@
 NAME = phusion/baseimage
-VERSION = 0.9.19
+VERSION = 0.9.20
 
 .PHONY: all build test tag_latest release ssh
 
@@ -18,7 +18,7 @@ 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
 	@if ! head -n 1 Changelog.md | grep -q 'release date'; then echo 'Please note the release date in Changelog.md.' && false; fi
 	docker push $(NAME)
-	@echo "*** Don't forget to create a tag. git tag rel-$(VERSION) && git push origin rel-$(VERSION)"
+	@echo "*** Don't forget to create a tag. git tag $(VERSION) && git push origin $(VERSION)"
 
 ssh:
 	chmod 600 image/services/sshd/keys/insecure_key

README.md

@@ -1,6 +1,7 @@
 # A minimal Ubuntu base image modified for Docker-friendliness
 
 [![](https://badge.imagelayers.io/phusion/baseimage:0.9.17.svg)](https://imagelayers.io/?images=phusion/baseimage:latest 'Get your own badge on imagelayers.io')
+[![Travis](https://img.shields.io/travis/phusion/baseimage-docker.svg)](https://travis-ci.org/phusion/baseimage-docker)
 
 _Baseimage-docker only consumes 6 MB RAM and is much powerful than Busybox or Alpine. See why below._
 
@@ -16,7 +17,7 @@ Baseimage-docker is available for pulling from [the Docker registry](https://reg
 
 ### What are the problems with the stock Ubuntu base image?
 
-Ubuntu is not designed to be run inside Docker. Its init system, Upstart, assumes that it's running on either real hardware or virtualized hardware, but not inside a Docker container. But inside a container you don't want a full system anyway, you want a minimal system. But configuring that minimal system for use within a container has many strange corner cases that are hard to get right if you are not intimately familiar with the Unix system model. This can cause a lot of strange problems.
+Ubuntu is not designed to be run inside Docker. Its init system, Upstart, assumes that it's running on either real hardware or virtualized hardware, but not inside a Docker container. But inside a container you don't want a full system; you want a minimal system.  Configuring that minimal system for use within a container has many strange corner cases that are hard to get right if you are not intimately familiar with the Unix system model. This can cause a lot of strange problems.
 
 Baseimage-docker gets everything right. The "Contents" section describes all the things that it modifies.
 
@@ -26,7 +27,7 @@ Baseimage-docker gets everything right. The "Contents" section describes all the
 You can configure the stock `ubuntu` image yourself from your Dockerfile, so why bother using baseimage-docker?
 
  * Configuring the base system for Docker-friendliness is no easy task. As stated before, there are many corner cases. By the time that you've gotten all that right, you've reinvented baseimage-docker. Using baseimage-docker will save you from this effort.
- * It reduces the time needed to write a correct Dockerfile. You won't have to worry about the base system and can focus on your stack and your app.
+ * It reduces the time needed to write a correct Dockerfile. You won't have to worry about the base system and focusing you on the stack and the app.
  * It reduces the time needed to run `docker build`, allowing you to iterate your Dockerfile more quickly.
  * It reduces download time during redeploys. Docker only needs to download the base image once: during the first deploy. On every subsequent deploys, only the changes you make on top of the base image are downloaded.
 
@@ -86,7 +87,7 @@ You can configure the stock `ubuntu` image yourself from your Dockerfile, so why
 | Component        | Why is it included? / Remarks |
 | ---------------- | ------------------- |
 | Ubuntu 16.04 LTS | The base system. |
-| 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. |
+| 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. 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 stops 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. |
 | 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".<br><br>Why syslog-ng?<br>I've had bad experience with rsyslog. I regularly run into bugs with rsyslog, and once in a while it takes my log host down by entering a 100% CPU loop in which it can't do anything. Syslog-ng seems to be much more stable. |
 | logrotate | Rotates and compresses logs on a regular basis. |
@@ -111,11 +112,11 @@ Do we advocate running multiple *logical services* in a single container? Not ne
 <a name="fat_containers"></a>
 ### Does Baseimage-docker advocate "fat containers" or "treating containers as VMs"?
 
-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.
+There are people who think that Baseimage-docker advocates treating containers as VMs because Baseimage-docker advocates the use of multiple processes. Therefore, they also think that Baseimage-docker does not follow the Docker philosophy. Neither of these impressions are true.
 
 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.
+It follows 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 providing [a mechanism to easily work with environment variables](#environment_variables) in the presence of multiple processes that may run as different users.
 
 <a name="inspecting"></a>
 ## Inspecting baseimage-docker
@@ -214,7 +215,7 @@ If you use `/sbin/my_init` as the main container command, then any environment v
 <a name="envvar_central_definition"></a>
 #### Centrally defining your own environment variables
 
-During startup, before running any [startup scripts](#running_startup_scripts), `my_init` imports environment variables from the directory `/etc/container_environment`. This directory contains files who are named after the environment variable names. The file contents contain the environment variable values. This directory is therefore a good place to centrally define your own environment variables, which will be inherited by all startup scripts and Runit services.
+During startup, before running any [startup scripts](#running_startup_scripts), `my_init` imports environment variables from the directory `/etc/container_environment`. This directory contains files named after the environment variable names. The file contents contain the environment variable values. This directory is therefore a good place to centrally define your own environment variables, which will be inherited by all startup scripts and Runit services.
 
 For example, here's how you can define an environment variable from your Dockerfile:
 
@@ -230,14 +231,14 @@ You can verify that it works, as follows:
 
 **Handling newlines**
 
-If you've looked carefully, you'll notice that the 'echo' command actually prints a newline. Why does $MY_NAME not contain a newline then? It's because `my_init` strips the trailing newline, if any. If you intended on the value having a newline, you should add *another* newline, like this:
+If you've looked carefully, you'll notice that the 'echo' command actually prints a newline. Why does $MY_NAME not contain a newline then? It's because `my_init` strips the trailing newline. If you intended on the value having a newline, you should add *another* newline, like this:
 
     RUN echo -e "Apachai Hopachai\n" > /etc/container_environment/MY_NAME
 
 <a name="envvar_dumps"></a>
 #### Environment variable dumps
 
-While the previously mentioned mechanism is good for centrally defining environment variables, it by itself does not prevent services (e.g. Nginx) from changing and resetting environment variables from child processes. However, the `my_init` mechanism does make it easy for you to query what the original environment variables are.
+While the previously mentioned mechanism is good for centrally defining environment variables, itself does not prevent services (e.g. Nginx) from changing and resetting environment variables from child processes. However, the `my_init` mechanism does make it easy for you to query what the original environment variables are.
 
 During startup, right after importing environment variables from `/etc/container_environment`, `my_init` will dump all its environment variables (that is, all variables imported from `container_environment`, as well as all variables it picked up from `docker run --env`) to the following locations, in the following formats:
 
@@ -245,7 +246,7 @@ During startup, right after importing environment variables from `/etc/container
  * `/etc/container_environment.sh` - a dump of the environment variables in Bash format. You can source the file directly from a Bash shell script.
  * `/etc/container_environment.json` - a dump of the environment variables in JSON format.
 
-The multiple formats makes it easy for you to query the original environment variables no matter which language your scripts/apps are written in.
+The multiple formats make it easy for you to query the original environment variables no matter which language your scripts/apps are written in.
 
 Here is an example shell session showing you how the dumps look like:
 
@@ -278,7 +279,7 @@ But note that:
 <a name="envvar_security"></a>
 #### Security
 
-Because environment variables can potentially contain sensitive information, `/etc/container_environment` and its Bash and JSON dumps are by default owned by root, and accessible only by the `docker_env` group (so that any user added this group will have these variables automatically loaded).
+Because environment variables can potentially contain sensitive information, `/etc/container_environment` and its Bash and JSON dumps are by default owned by root, and accessible only to the `docker_env` group (so that any user added this group will have these variables automatically loaded).
 
 If you are sure that your environment variables don't contain sensitive data, then you can also relax the permissions on that directory and those files by making them world-readable:
 
@@ -290,7 +291,7 @@ If you are sure that your environment variables don't contain sensitive data, th
 
 Baseimage-docker images contain an Ubuntu 16.04 operating system. You may want to update this OS from time to time, for example to pull in the latest security updates. OpenSSL is a notorious example. Vulnerabilities are discovered in OpenSSL on a regular basis, so you should keep OpenSSL up-to-date as much as you can.
 
-While we release Baseimage-docker images with the latest OS updates from time to time, you do not have to rely on us. You can update the OS inside Baseimage-docker images yourself, and it is recommend that you do this instead of waiting for us.
+While we release Baseimage-docker images with the latest OS updates from time to time, you do not have to rely on us. You can update the OS inside Baseimage-docker images yourself, and it is recommended that you do this instead of waiting for us.
 
 To upgrade the OS in the image, run this in your Dockerfile:
 

image/Dockerfile

@@ -1,4 +1,4 @@
-FROM i386/ubuntu:16.04
+FROM ubuntu:16.04
 MAINTAINER Phusion <info@phusion.nl>
 
 COPY . /bd_build
@@ -6,7 +6,6 @@ COPY . /bd_build
 RUN /bd_build/prepare.sh && \
 	/bd_build/system_services.sh && \
 	/bd_build/utilities.sh && \
-	/bd_build/fix_libgc_bug.sh && \
 	/bd_build/fix_pam_bug.sh && \
 	/bd_build/cleanup.sh
 

image/fix_libgc_bug.sh

@@ -1,41 +0,0 @@
-#!/bin/bash
-set -e
-source /bd_build/buildconfig
-set -x
-
-# Fixes https://github.com/docker/docker/issues/6345
-# The Github is closed, but some apps such as pbuilder still triggers it.
-
-export CONFIGURE_OPTS=--disable-audit
-cd /tmp
-
-$minimal_apt_get_install gdebi-core
-apt-get build-dep -y --no-install-recommends libgc
-apt-get source -y libgc
-echo "#define NO_GETCONTEXT" >> libgc-7.4.2/include/private/gcconfig.h
-pushd libgc-7.4.2
-dpkg-buildpackage -b
-popd
-gdebi -n libgc1c2_7.4.2-7.3ubuntu0.1_i386.deb
-rm -rf *.deb *.gz *.dsc *.changes libgc-*
-
-# Unfortunately there is no way to automatically remove build deps, so we do this manually.
-apt-get remove -y gdebi-core autoconf automake autopoint autotools-dev binutils bsdmainutils \
-	build-essential bzip2 cpp cpp-5 debhelper dh-autoreconf dh-strip-nondeterminism \
-	diffstat dpkg-dev g++ g++-5 gcc gcc-5 gettext gettext-base groff-base hardening-includes \
-	intltool-debian libapt-pkg-perl libarchive-zip-perl libasan2 libasprintf0v5 libatomic-ops-dev \
-	libatomic1 libc-dev-bin libc6-dev libcc1-0 libcgi-pm-perl libcilkrts5 libclass-accessor-perl \
-	libclone-perl libcroco3 libdata-alias-perl libdigest-hmac-perl libdpkg-perl libemail-valid-perl \
-	libexporter-tiny-perl libfile-basedir-perl libfile-stripnondeterminism-perl libgcc-5-dev libgdbm3 \
-	libgomp1 libhtml-parser-perl libhtml-tagset-perl libicu55 libio-pty-perl libio-socket-inet6-perl \
-	libio-socket-ssl-perl libio-string-perl libipc-run-perl libipc-system-simple-perl libisl15 \
-	libitm1 liblist-moreutils-perl liblocale-gettext-perl libmailtools-perl libmpc3 libmpfr4 libmpx0 \
-	libnet-dns-perl libnet-domain-tld-perl libnet-ip-perl libnet-smtp-ssl-perl libnet-ssleay-perl \
-	libparse-debianchangelog-perl libperl5.22 libpipeline1 libquadmath0 libsigsegv2 libsocket6-perl \
-	libstdc++-5-dev libsub-name-perl libtext-levenshtein-perl libtimedate-perl libtool libubsan0 \
-	libunistring0 liburi-perl libxml2 libyaml-libyaml-perl lintian linux-libc-dev m4 make man-db \
-	netbase patch patchutils perl perl-modules-5.22 pkg-config pkg-kde-tools po-debconf t1utils \
-	xz-utils
-
-apt-get remove -y gdebi-core
-apt-get autoremove -y

image/fix_pam_bug.sh

@@ -22,10 +22,10 @@ apt-get remove -y gdebi-core autoconf automake autopoint autotools-dev binutils
 	groff-base intltool-debian libarchive-zip-perl libasan2 libasprintf0v5 libatomic1 \
 	libaudit-dev libc-dev-bin libc6-dev libcc1-0 libcilkrts5 libcrack2 libcrack2-dev libcroco3 \
 	libdb-dev libdb5.3-dev libdpkg-perl libfile-stripnondeterminism-perl libfl-dev libgc1c2 \
-	libgcc-5-dev libgdbm3 libgomp1 libgpm2 libicu55 libisl15 libitm1 libmpc3 \
+	libgcc-5-dev libgdbm3 libgomp1 libgpm2 libicu55 libisl15 libitm1 liblsan0 libmpc3 \
 	libmpfr4 libmpx0 libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libperl5.22 \
 	libpipeline1 libquadmath0 libselinux1-dev libsepol1-dev libsigsegv2 libstdc++-5-dev \
-	libtimedate-perl libtool libubsan0 libunistring0 libxml2 libxml2-utils \
+	libtimedate-perl libtool libtsan0 libubsan0 libunistring0 libxml2 libxml2-utils \
 	libxslt1.1 linux-libc-dev m4 make man-db patch perl perl-modules-5.22 pkg-config \
 	po-debconf quilt sgml-base sgml-data w3m xml-core xsltproc xz-utils