{"id":13474728,"url":"https://github.com/phusion/baseimage-docker","last_synced_at":"2026-06-06T00:01:49.940Z","repository":{"id":39583873,"uuid":"14329321","full_name":"phusion/baseimage-docker","owner":"phusion","description":"A minimal Ubuntu base image modified for Docker-friendliness","archived":false,"fork":false,"pushed_at":"2026-06-02T17:16:22.000Z","size":2175,"stargazers_count":9097,"open_issues_count":0,"forks_count":1076,"subscribers_count":226,"default_branch":"master","last_synced_at":"2026-06-02T19:11:41.324Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://phusion.github.io/baseimage-docker/","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/phusion.png","metadata":{"files":{"readme":"README.md","changelog":"Changelog.md","contributing":"CONTRIBUTING.md","funding":".github/FUNDING.yml","license":"LICENSE.txt","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null},"funding":{"github":"samip5","custom":"https://www.buymeacoffee.com/skykrypt"}},"created_at":"2013-11-12T10:41:02.000Z","updated_at":"2026-06-02T17:09:09.000Z","dependencies_parsed_at":"2023-12-22T19:25:48.152Z","dependency_job_id":"d7ce86a5-d6e4-4b5a-8aba-14524be36886","html_url":"https://github.com/phusion/baseimage-docker","commit_stats":{"total_commits":438,"total_committers":113,"mean_commits":"3.8761061946902653","dds":0.5776255707762556,"last_synced_commit":"f3a14b25e93554024abfb58bd59164c2e8865b5c"},"previous_names":[],"tags_count":44,"template":false,"template_full_name":null,"purl":"pkg:github/phusion/baseimage-docker","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phusion%2Fbaseimage-docker","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phusion%2Fbaseimage-docker/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phusion%2Fbaseimage-docker/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phusion%2Fbaseimage-docker/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/phusion","download_url":"https://codeload.github.com/phusion/baseimage-docker/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phusion%2Fbaseimage-docker/sbom","scorecard":{"id":732755,"data":{"date":"2025-08-11","repo":{"name":"github.com/phusion/baseimage-docker","commit":"2403c5825475dbc95d4a44ab91406e20f391c7c5"},"scorecard":{"version":"v5.2.1-40-gf6ed084d","commit":"f6ed084d17c9236477efd66e5b258b9d4cc7b389"},"score":4.7,"checks":[{"name":"Code-Review","score":6,"reason":"Found 14/23 approved changesets -- score normalized to 6","details":null,"documentation":{"short":"Determines if the project requires human code review before pull requests (aka merge requests) are merged.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#code-review"}},{"name":"Dangerous-Workflow","score":10,"reason":"no dangerous workflow patterns detected","details":null,"documentation":{"short":"Determines if the project's GitHub Action workflows avoid dangerous patterns.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#dangerous-workflow"}},{"name":"Binary-Artifacts","score":9,"reason":"binaries present in source code","details":["Warn: binary detected: tools/baseimage-docker-nsenter:1"],"documentation":{"short":"Determines if the project has generated executable (binary) artifacts in the source repository.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#binary-artifacts"}},{"name":"Maintained","score":0,"reason":"0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0","details":null,"documentation":{"short":"Determines if the project is \"actively maintained\".","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#maintained"}},{"name":"CII-Best-Practices","score":0,"reason":"no effort to earn an OpenSSF best practices badge detected","details":null,"documentation":{"short":"Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#cii-best-practices"}},{"name":"Token-Permissions","score":0,"reason":"detected GitHub workflow tokens with excessive permissions","details":["Warn: no topLevel permission defined: .github/workflows/main.yml:1","Warn: no topLevel permission defined: .github/workflows/stale.yml:1","Info: no jobLevel write permissions found"],"documentation":{"short":"Determines if the project's workflows follow the principle of least privilege.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#token-permissions"}},{"name":"Pinned-Dependencies","score":0,"reason":"dependency not pinned by hash detected -- score normalized to 0","details":["Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/main.yml:13: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/main.yml/master?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/main.yml:38: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/main.yml/master?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/main.yml:43: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/main.yml/master?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/main.yml:52: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/main.yml/master?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/main.yml:61: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/main.yml/master?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/main.yml:67: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/main.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/stale.yml:10: update your workflow using https://app.stepsecurity.io/secureworkflow/phusion/baseimage-docker/stale.yml/master?enable=pin","Warn: containerImage not pinned by hash: image/Dockerfile:2","Info:   0 out of   2 GitHub-owned GitHubAction dependencies pinned","Info:   0 out of   5 third-party GitHubAction dependencies pinned","Info:   0 out of   1 containerImage dependencies pinned"],"documentation":{"short":"Determines if the project has declared and pinned the dependencies of its build process.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#pinned-dependencies"}},{"name":"Security-Policy","score":0,"reason":"security policy file not detected","details":["Warn: no security policy file detected","Warn: no security file to analyze","Warn: no security file to analyze","Warn: no security file to analyze"],"documentation":{"short":"Determines if the project has published a security policy.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#security-policy"}},{"name":"Vulnerabilities","score":10,"reason":"0 existing vulnerabilities detected","details":null,"documentation":{"short":"Determines if the project has open, known unfixed vulnerabilities.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#vulnerabilities"}},{"name":"Fuzzing","score":0,"reason":"project is not fuzzed","details":["Warn: no fuzzer integrations found"],"documentation":{"short":"Determines if the project uses fuzzing.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#fuzzing"}},{"name":"License","score":10,"reason":"license file detected","details":["Info: project has a license file: LICENSE.txt:0","Info: FSF or OSI recognized license: MIT License: LICENSE.txt:0"],"documentation":{"short":"Determines if the project has defined a license.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#license"}},{"name":"Packaging","score":10,"reason":"packaging workflow detected","details":["Info: Project packages its releases by way of GitHub Actions.: .github/workflows/main.yml:8"],"documentation":{"short":"Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#packaging"}},{"name":"Signed-Releases","score":-1,"reason":"no releases found","details":null,"documentation":{"short":"Determines if the project cryptographically signs release artifacts.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#signed-releases"}},{"name":"Branch-Protection","score":-1,"reason":"internal error: error during branchesHandler.setup: internal error: githubv4.Query: Resource not accessible by integration","details":null,"documentation":{"short":"Determines if the default and release branches are protected with GitHub's branch protection settings.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#branch-protection"}},{"name":"SAST","score":0,"reason":"SAST tool is not run on all commits -- score normalized to 0","details":["Warn: 0 commits out of 24 are checked with a SAST tool"],"documentation":{"short":"Determines if the project uses static code analysis.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#sast"}}]},"last_synced_at":"2025-08-22T14:53:41.782Z","repository_id":39583873,"created_at":"2025-08-22T14:53:41.782Z","updated_at":"2025-08-22T14:53:41.782Z"},"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33964367,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-05T02:00:06.157Z","response_time":120,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T16:01:14.367Z","updated_at":"2026-06-06T00:01:49.914Z","avatar_url":"https://github.com/phusion.png","language":"Shell","funding_links":["https://github.com/sponsors/samip5","https://www.buymeacoffee.com/skykrypt"],"categories":["Shell","Useful Images","others","Python"],"sub_categories":[],"readme":"# A minimal Ubuntu base image modified for Docker-friendliness\n\n[![Release](https://github.com/phusion/baseimage-docker/actions/workflows/main.yml/badge.svg)](https://github.com/phusion/baseimage-docker/actions/workflows/main.yml)\n\n_Baseimage-docker only consumes 8.3 MB RAM and is much more powerful than Busybox or Alpine. See why below._\n\nBaseimage-docker is a special [Docker](https://www.docker.com) image that is configured for correct use within Docker containers. It is Ubuntu, plus:\n\n * Modifications for Docker-friendliness.\n * Administration tools that are especially useful in the context of Docker.\n * Mechanisms for easily running multiple processes, [without violating the Docker philosophy](#docker_single_process).\n\nYou can use it as a base for your own Docker images.\n\nBaseimage-docker is available for pulling from [the Docker registry](https://hub.docker.com/r/phusion/baseimage) and [GHCR (GitHub Container Registry)](https://github.com/phusion/baseimage-docker/pkgs/container/baseimage)!\n\n### What are the problems with the stock Ubuntu base image?\n\nUbuntu 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.\n\nBaseimage-docker gets everything right. The \"Contents\" section describes all the things that it modifies.\n\n\u003ca name=\"why_use\"\u003e\u003c/a\u003e\n### Why use baseimage-docker?\n\nYou can configure the stock `ubuntu` image yourself from your Dockerfile, so why bother using baseimage-docker?\n\n * 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.\n * It reduces the time needed to write a correct Dockerfile. You won't have to worry about the base system and you can focus on the stack and the app.\n * It reduces the time needed to run `docker build`, allowing you to iterate your Dockerfile more quickly.\n * 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.\n\n-----------------------------------------\n\n**Related resources**:\n  [Website](http://phusion.github.io/baseimage-docker/) |\n  [Github](https://github.com/phusion/baseimage-docker) |\n  [Docker registry](https://registry.hub.docker.com/r/phusion/baseimage/) |\n  [Discussion forum](https://groups.google.com/d/forum/passenger-docker) |\n  [Twitter](https://twitter.com/phusion_nl) |\n  [Blog](http://blog.phusion.nl/)\n\n**Table of contents**\n\n * [What's inside the image?](#whats_inside)\n   * [Overview](#whats_inside_overview)\n   * [Wait, I thought Docker is about running a single process in a container?](#docker_single_process)\n   * [Does Baseimage-docker advocate \"fat containers\" or \"treating containers as VMs\"?](#fat_containers)\n * [Inspecting baseimage-docker](#inspecting)\n * [Using baseimage-docker as base image](#using)\n   * [Getting started](#getting_started)\n   * [Adding additional daemons](#adding_additional_daemons)\n   * [Running scripts during container startup](#running_startup_scripts)\n   * [Environment variables](#environment_variables)\n     * [Centrally defining your own environment variables](#envvar_central_definition)\n     * [Environment variable dumps](#envvar_dumps)\n     * [Modifying environment variables](#modifying_envvars)\n     * [Security](#envvar_security)\n   * [System logging](#logging)\n   * [Upgrading the operating system inside the container](#upgrading_os)\n * [Container administration](#container_administration)\n   * [Running a one-shot command in a new container](#oneshot)\n   * [Running a command in an existing, running container](#run_inside_existing_container)\n   * [Login to the container via `docker exec`](#login_docker_exec)\n     * [Usage](#docker_exec)\n   * [Login to the container via SSH](#login_ssh)\n     * [Enabling SSH](#enabling_ssh)\n     * [About SSH keys](#ssh_keys)\n     * [Using the insecure key for one container only](#using_the_insecure_key_for_one_container_only)\n     * [Enabling the insecure key permanently](#enabling_the_insecure_key_permanently)\n     * [Using your own key](#using_your_own_key)\n     * [The `docker-ssh` tool](#docker_ssh)\n * [Building the image yourself](#building)\n   * [Removing optional services](#removing_optional_services)\n   * [Ubuntu 26.04 LTS: Rust Coreutils](#ubuntu_2604_rust)\n * [Conclusion](#conclusion)\n\n-----------------------------------------\n\n\u003ca name=\"whats_inside\"\u003e\u003c/a\u003e\n## What's inside the image?\n\n\u003ca name=\"whats_inside_overview\"\u003e\u003c/a\u003e\n### Overview\n\n*Looking for a more complete base image, one that is ideal for Ruby, Python, Node.js and Meteor web apps? Take a look at [passenger-docker](https://github.com/phusion/passenger-docker).*\n\n| Component        | Why is it included? / Remarks |\n| ---------------- | ------------------- |\n| Ubuntu 26.04 LTS (Resolute) or 24.04 LTS (Noble) | The base system. Ubuntu 26.04 \"Resolute\" is the latest LTS; 24.04 \"Noble\" and 22.04 \"Jammy\" tracks are also maintained. **Note:** Ubuntu 26.04 ships [Rust Coreutils (uutils coreutils)](#ubuntu_2604_rust) instead of GNU Coreutils. See the [dedicated section](#ubuntu_2604_rust) for details and alternatives. |\n| 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/)._ \u003cbr\u003e\u003cbr\u003eAccording 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. \u003cbr\u003e\u003cbr\u003eFurthermore, `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. \u003cbr\u003e\u003cbr\u003eBaseimage-docker comes with an init process `/sbin/my_init` that performs both of these tasks correctly. |\n| Fixes APT incompatibilities with Docker | See https://github.com/dotcloud/docker/issues/1024. |\n| 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. \u003cbr\u003e\u003cbr\u003eOnly listens locally. All syslog messages are forwarded to \"docker logs\".\u003cbr\u003e\u003cbr\u003eWhy syslog-ng?\u003cbr\u003eI'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. |\n| logrotate | Rotates and compresses logs on a regular basis. |\n| SSH server | Allows you to easily login to your container to [inspect or administer](#login_ssh) things. \u003cbr\u003e\u003cbr\u003e_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._\u003cbr\u003e\u003cbr\u003ePassword and challenge-response authentication are disabled by default. Only key authentication is allowed. |\n| cron | The cron daemon must be running for cron jobs to work. |\n| [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. |\n| `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`. |\n| `install_clean` | A tool for installing `apt` packages that automatically cleans up after itself.  All arguments are passed to `apt-get -y install --no-install-recommends` and after installation the apt caches are cleared.  To include recommended packages, add `--install-recommends`. |\n\nBaseimage-docker is very lightweight: it only consumes 8.3 MB of memory.\n\n\u003ca name=\"docker_single_process\"\u003e\u003c/a\u003e\n### Wait, I thought Docker is about running a single process in a container?\n\nThe Docker developers advocate the philosophy of running a single *logical service* per container. A logical service can consist of multiple OS processes.\n\nBaseimage-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.\n\nSplitting 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.\n\nDo we advocate running multiple *logical services* in a single container? Not necessarily, but we do not prohibit it either. While the Docker developers are very opinionated and have very rigid philosophies about how containers *should* be built, Baseimage-docker is completely unopinionated. We believe in freedom: sometimes it makes sense to run multiple services in a single container, and sometimes it doesn't. It is up to you to decide what makes sense, not the Docker developers.\n\n\u003ca name=\"fat_containers\"\u003e\u003c/a\u003e\n### Does Baseimage-docker advocate \"fat containers\" or \"treating containers as VMs\"?\n\nThere 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.\n\nThe 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.\n\nIt 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.\n\n\u003ca name=\"inspecting\"\u003e\u003c/a\u003e\n## Inspecting baseimage-docker\n\nTo look around in the image, run:\n\n    docker run --rm -t -i phusion/baseimage:\u003cVERSION\u003e /sbin/my_init -- bash -l\n\nwhere `\u003cVERSION\u003e` is [one of the baseimage-docker version numbers](https://github.com/phusion/baseimage-docker/blob/master/Changelog.md).\n\nYou don't have to download anything manually. The above command will automatically pull the baseimage-docker image from the Docker registry.\n\n\u003ca name=\"using\"\u003e\u003c/a\u003e\n## Using baseimage-docker as base image\n\n\u003ca name=\"getting_started\"\u003e\u003c/a\u003e\n### Getting started\n\nThe image is called `phusion/baseimage`, and is available on the Docker registry.\n\n    # Use phusion/baseimage as base image. To make your builds reproducible, make\n    # sure you lock down to a specific version, not to `latest`!\n    # See https://github.com/phusion/baseimage-docker/blob/master/Changelog.md for\n    # a list of version numbers.\n    FROM phusion/baseimage:\u003cVERSION\u003e\n\n    # Use baseimage-docker's init system.\n    CMD [\"/sbin/my_init\"]\n\n    # ...put your own build instructions here...\n\n    # Clean up APT when done.\n    RUN apt-get clean \u0026\u0026 rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*\n\n\u003ca name=\"adding_additional_daemons\"\u003e\u003c/a\u003e\n### Adding additional daemons\n\nA daemon is a program which runs in the background of its system, such\nas a web server.\n\nYou can add additional daemons (for example, your own app) to the image\nby creating runit service directories. You only have to write a small\nshell script which runs your daemon;\n[`runsv`](http://smarden.org/runit/runsv.8.html) will start your script,\nand - by default - restart it upon its exit, after waiting one second.\n\nThe shell script must be called `run`, must be executable, and is to be\nplaced in the directory `/etc/service/\u003cNAME\u003e`. `runsv` will switch to\nthe directory and invoke `./run` after your container starts.\n\n**Be certain that you do not start your container using interactive mode\n(`-it`) with another command, as `runit` must be the first process to run. If you do this, your runit service directories won't be started. For instance, `docker run -it \u003cname\u003e bash` will bring you to bash in your container, but you'll lose all your daemons.**\n\nHere's an example showing you how a `runit` service directory can be\nmade for a `memcached` server.\n\nIn `memcached.sh`, or whatever you choose to name your file (make sure\nthis file is chmod +x):\n```bash\n#!/bin/sh\n# `/sbin/setuser memcache` runs the given command as the user `memcache`.\n# If you omit that part, the command will be run as root.\nexec /sbin/setuser memcache /usr/bin/memcached \u003e\u003e/var/log/memcached.log 2\u003e\u00261\n```\nIn an accompanying `Dockerfile`:\n\n```Dockerfile\nRUN mkdir /etc/service/memcached\nCOPY memcached.sh /etc/service/memcached/run\nRUN chmod +x /etc/service/memcached/run\n```\nA given shell script must run **without daemonizing or forking itself**;\nthis is because `runit` will start and restart your script on its own.\nUsually, daemons provide a command line flag or a config file option for\npreventing such behavior - essentially, you just want your script to run\nin the foreground, not the background.\n\n\u003ca name=\"running_startup_scripts\"\u003e\u003c/a\u003e\n### Running scripts during container startup\n\nThe baseimage-docker init system, `/sbin/my_init`, runs the following scripts during startup, in the following order:\n\n * All executable scripts in `/etc/my_init.d`, if this directory exists. The scripts are run in lexicographic order.\n * The script `/etc/rc.local`, if this file exists.\n\nAll scripts must exit correctly, e.g. with exit code 0. If any script exits with a non-zero exit code, the booting will fail.\n\n**Important note:** If you are executing the container in interactive mode (i.e. when you run a container with `-it`), rather than daemon mode, you are sending stdout directly to the terminal (`-i` interactive `-t` terminal). If you are not calling `/sbin/my_init` in your run declaration, `/sbin/my_init` will not be executed, therefore your scripts will not be called during container startup.\n\nThe following example shows how you can add a startup script. This script simply logs the time of boot to the file /tmp/boottime.txt.\n\nIn `logtime.sh`:\n\n    #!/bin/sh\n    date \u003e /tmp/boottime.txt\n\nIn `Dockerfile`:\n\n    RUN mkdir -p /etc/my_init.d\n    COPY logtime.sh /etc/my_init.d/logtime.sh\n    RUN chmod +x /etc/my_init.d/logtime.sh\n\n\u003ca name=\"environment_variables\"\u003e\u003c/a\u003e\n\n#### Shutting down your process\n\n`/sbin/my_init` handles termination of children processes at shutdown. When it receives a SIGTERM\nit will pass the signal onto the child processes for correct shutdown. If your process is started with\na shell script, make sure you `exec` the actual process, otherwise the shell will receive the signal\nand not your process.\n\n`/sbin/my_init` will terminate processes after a 5 second timeout. This can be adjusted by setting\nenvironment variables:\n\n    # Give children processes 5 minutes to timeout\n    ENV KILL_PROCESS_TIMEOUT=300\n    # Give all other processes (such as those which have been forked) 5 minutes to timeout\n    ENV KILL_ALL_PROCESSES_TIMEOUT=300\n\nNote: Prior to 0.11.1, the default values for `KILL_PROCESS_TIMEOUT` and `KILL_ALL_PROCESSES_TIMEOUT`\nwere 5 seconds. In version 0.11.1+ the default process timeout has been adjusted to 30 seconds to\nallow more time for containers to terminate gracefully. The default timeout of your container runtime\nmay supersede this setting, for example Docker currently applies a [10s timeout](https://docs.docker.com/engine/reference/commandline/stop/#options)\nby default before sending SIGKILL, upon `docker stop` or receiving SIGTERM.\n\n### Environment variables\n\nIf you use `/sbin/my_init` as the main container command, then any environment variables set with `docker run --env` or with the `ENV` command in the Dockerfile, will be picked up by `my_init`. These variables will also be passed to all child processes, including `/etc/my_init.d` startup scripts, Runit and Runit-managed services. There are however a few caveats you should be aware of:\n\n * Environment variables on Unix are inherited on a per-process basis. This means that it is generally not possible for a child process to change the environment variables of other processes.\n * Because of the aforementioned point, there is no good central place for defining environment variables for all applications and services. Debian has the `/etc/environment` file but it only works in some situations.\n * Some services change environment variables for child processes. Nginx is one such example: it removes all environment variables unless you explicitly instruct it to retain them through the `env` configuration option. If you host any applications on Nginx (e.g. using the [passenger-docker](https://github.com/phusion/passenger-docker) image, or using Phusion Passenger in your own image) then they will not see the environment variables that were originally passed by Docker.\n * We ignore HOME, SHELL, USER and a bunch of other environment variables on purpose, because _not_ ignoring them will break multi-user containers. See https://github.com/phusion/baseimage-docker/pull/86 -- A workaround for setting the `HOME` environment variable looks like this: `RUN echo /root \u003e /etc/container_environment/HOME`. See https://github.com/phusion/baseimage-docker/issues/119\n\n`my_init` provides a solution for all these caveats.\n\n\u003ca name=\"envvar_central_definition\"\u003e\u003c/a\u003e\n#### Centrally defining your own environment variables\n\nDuring 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.\n\nFor example, here's how you can define an environment variable from your Dockerfile:\n\n    RUN echo Apachai Hopachai \u003e /etc/container_environment/MY_NAME\n\nYou can verify that it works, as follows:\n\n    $ docker run -t -i \u003cYOUR_NAME_IMAGE\u003e /sbin/my_init -- bash -l\n    ...\n    *** Running bash -l...\n    # echo $MY_NAME\n    Apachai Hopachai\n\n**Handling newlines**\n\nIf 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:\n\n    RUN echo -e \"Apachai Hopachai\\n\" \u003e /etc/container_environment/MY_NAME\n\n\u003ca name=\"envvar_dumps\"\u003e\u003c/a\u003e\n#### Environment variable dumps\n\nWhile 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.\n\nDuring 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:\n\n * `/etc/container_environment`\n * `/etc/container_environment.sh` - a dump of the environment variables in Bash format. You can source the file directly from a Bash shell script.\n * `/etc/container_environment.json` - a dump of the environment variables in JSON format.\n\nThe multiple formats make it easy for you to query the original environment variables no matter which language your scripts/apps are written in.\n\nHere is an example shell session showing you how the dumps look like:\n\n    $ docker run -t -i \\\n      --env FOO=bar --env HELLO='my beautiful world' \\\n      phusion/baseimage:\u003cVERSION\u003e /sbin/my_init -- \\\n      bash -l\n    ...\n    *** Running bash -l...\n    # ls /etc/container_environment\n    FOO  HELLO  HOME  HOSTNAME  PATH  TERM  container\n    # cat /etc/container_environment/HELLO; echo\n    my beautiful world\n    # cat /etc/container_environment.json; echo\n    {\"TERM\": \"xterm\", \"container\": \"lxc\", \"HOSTNAME\": \"f45449f06950\", \"HOME\": \"/root\", \"PATH\": \"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\", \"FOO\": \"bar\", \"HELLO\": \"my beautiful world\"}\n    # source /etc/container_environment.sh\n    # echo $HELLO\n    my beautiful world\n\n\u003ca name=\"modifying_envvars\"\u003e\u003c/a\u003e\n#### Modifying environment variables\n\nIt is even possible to modify the environment variables in `my_init` (and therefore the environment variables in all child processes that are spawned after that point in time), by altering the files in `/etc/container_environment`. After each time `my_init` runs a [startup script](#running_startup_scripts), it resets its own environment variables to the state in `/etc/container_environment`, and re-dumps the new environment variables to `container_environment.sh` and `container_environment.json`.\n\nBut note that:\n\n * modifying `container_environment.sh` and `container_environment.json` has no effect.\n * Runit services cannot modify the environment like that. `my_init` only activates changes in `/etc/container_environment` when running startup scripts.\n\n\u003ca name=\"envvar_security\"\u003e\u003c/a\u003e\n#### Security\n\nBecause 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).\n\nIf 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:\n\n    RUN chmod 755 /etc/container_environment\n    RUN chmod 644 /etc/container_environment.sh /etc/container_environment.json\n\n\u003ca name=\"logging\"\u003e\u003c/a\u003e\n### System logging\n\nBaseimage-docker uses syslog-ng to provide a syslog facility to the container. Syslog-ng is not managed as an runit service (see below). Syslog messages are forwarded to the console.\n\n#### Log startup/shutdown sequence\nIn order to ensure that all application log messages are captured by syslog-ng, syslog-ng is started separately before the runit supervisor process, and shutdown after runit exits. This uses the [startup script facility](#running_startup_scripts) provided by this image. This avoids a race condition which would exist if syslog-ng were managed as an runit service, where runit kills syslog-ng in parallel with the container's other services, causing log messages to be dropped during a graceful shutdown if syslog-ng exits while logs are still being produced by other services.\n\n\u003ca name=\"upgrading_os\"\u003e\u003c/a\u003e\n### Upgrading the operating system inside the container\n\nBaseimage-docker images contain an Ubuntu operating system (see OS version at [Overview](#overview)). 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.\n\nWhile 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.\n\nTo upgrade the OS in the image, run this in your Dockerfile:\n\n    RUN apt-get update \u0026\u0026 apt-get upgrade -y -o Dpkg::Options::=\"--force-confold\"\n\n\u003ca name=\"container_administration\"\u003e\u003c/a\u003e\n## Container administration\n\nOne of the ideas behind Docker is that containers should be stateless, easily restartable, and behave like a black box. However, you may occasionally encounter situations where you want to login to a container, or to run a command inside a container, for development, inspection and debugging purposes. This section describes how you can administer the container for those purposes.\n\n\u003ca name=\"oneshot\"\u003e\u003c/a\u003e\n### Running a one-shot command in a new container\n\n_**Note:** This section describes how to run a command insider a -new- container. To run a command inside an existing running container, see [Running a command in an existing, running container](#run_inside_existing_container)._\n\nNormally, when you want to create a new container in order to run a single command inside it, and immediately exit after the command exits, you invoke Docker like this:\n\n    docker run YOUR_IMAGE COMMAND ARGUMENTS...\n\nHowever the downside of this approach is that the init system is not started. That is, while invoking `COMMAND`, important daemons such as cron and syslog are not running. Also, orphaned child processes are not properly reaped, because `COMMAND` is PID 1.\n\nBaseimage-docker provides a facility to run a single one-shot command, while solving all of the aforementioned problems. Run a single command in the following manner:\n\n    docker run YOUR_IMAGE /sbin/my_init -- COMMAND ARGUMENTS ...\n\nThis will perform the following:\n\n * Runs all system startup files, such as /etc/my_init.d/* and /etc/rc.local.\n * Starts all runit services.\n * Runs the specified command.\n * When the specified command exits, stops all runit services.\n\nFor example:\n\n    $ docker run phusion/baseimage:\u003cVERSION\u003e /sbin/my_init -- ls\n    *** Running /etc/rc.local...\n    *** Booting runit daemon...\n    *** Runit started as PID 80\n    *** Running ls...\n    bin  boot  dev  etc  home  image  lib  lib64  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var\n    *** ls exited with exit code 0.\n    *** Shutting down runit daemon (PID 80)...\n    *** Killing all processes...\n\nYou may find that the default invocation is too noisy. Or perhaps you don't want to run the startup files. You can customize all this by passing arguments to `my_init`. Invoke `docker run YOUR_IMAGE /sbin/my_init --help` for more information.\n\nThe following example runs `ls` without running the startup files and with less messages, while running all runit services:\n\n    $ docker run phusion/baseimage:\u003cVERSION\u003e /sbin/my_init --skip-startup-files --quiet -- ls\n    bin  boot  dev  etc  home  image  lib  lib64  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var\n\n\u003ca name=\"run_inside_existing_container\"\u003e\u003c/a\u003e\n### Running a command in an existing, running container\n\nThere are two ways to run a command inside an existing, running container.\n\n * 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).\n * 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).\n\nBoth way have their own pros and cons, which you can learn in their respective subsections.\n\n\u003ca name=\"login_docker_exec\"\u003e\u003c/a\u003e\n### Login to the container, or running a command inside it, via `docker exec`\n\nYou 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.\n\nHere's how it compares to [using SSH to login to the container or to run a command inside it](#login_ssh):\n\n * Pros\n   * Does not require running an SSH daemon inside the container.\n   * Does not require setting up SSH keys.\n   * Works on any container, even containers not based on baseimage-docker.\n * Cons\n   * 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`.\n   * 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.\n   * Not possible to allow users to login to the container without also letting them login to the Docker host.\n\n\u003ca name=\"docker_exec_usage\"\u003e\u003c/a\u003e\n#### Usage\n\nStart a container:\n\n    docker run YOUR_IMAGE\n\nFind out the ID of the container that you just ran:\n\n    docker ps\n\nNow that you have the ID, you can use `docker exec` to run arbitrary commands in the container. For example, to run `echo hello world`:\n\n    docker exec YOUR-CONTAINER-ID echo hello world\n\nTo open a bash session inside the container, you must pass `-t -i` so that a terminal is available:\n\n    docker exec -t -i YOUR-CONTAINER-ID bash -l\n\n\u003ca name=\"login_ssh\"\u003e\u003c/a\u003e\n### Login to the container, or running a command inside it, via SSH\n\nYou 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.\n\nHere's how it compares to [using `docker exec` to login to the container or to run a command inside it](#login_docker_exec):\n\n * Pros\n   * Does not require root privileges on the Docker host.\n   * 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.\n * Cons\n   * Requires setting up SSH keys. However, baseimage-docker makes this easy for many cases through a pregenerated, insecure key. Read on to learn more.\n\n\u003ca name=\"enabling_ssh\"\u003e\u003c/a\u003e\n#### Enabling SSH\n\nBaseimage-docker disables the SSH server by default. Add the following to your Dockerfile to enable it:\n\n    RUN rm -f /etc/service/sshd/down\n\n    # Regenerate SSH host keys. baseimage-docker does not contain any, so you\n    # have to do that yourself. You may also comment out this instruction; the\n    # init system will auto-generate one during boot.\n    RUN /etc/my_init.d/00_regen_ssh_host_keys.sh\n\nAlternatively, to enable sshd only for a single instance of your container, create a folder with a [startup script](#running_startup_scripts).  The contents of that should be\n\n    ### In myfolder/enable_ssh.sh (make sure this file is chmod +x):\n    #!/bin/sh\n    rm -f /etc/service/sshd/down\n    ssh-keygen -P \"\" -t dsa -f /etc/ssh/ssh_host_dsa_key\n\nThen, you can start your container with\n\n    docker run -d -v `pwd`/myfolder:/etc/my_init.d my/dockerimage\n\nThis will initialize sshd on container boot.  You can then access it with the insecure key as below, or using the methods to add a secure key.  Further, you can publish the port to your machine with -p 2222:22 allowing you to ssh to 127.0.0.1:2222 instead of looking up the ip address of the container.\n\n\u003ca name=\"ssh_keys\"\u003e\u003c/a\u003e\n#### About SSH keys\n\nFirst, 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/services/sshd/keys/insecure_key) [(PuTTY format)](https://github.com/phusion/baseimage-docker/blob/master/image/services/sshd/keys/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**.\n\n\u003ca name=\"using_the_insecure_key_for_one_container_only\"\u003e\u003c/a\u003e\n#### Using the insecure key for one container only\n\nYou can temporarily enable the insecure key for one container only. This means that the insecure key is installed at container boot. If you `docker stop` and `docker start` the container, the insecure key will still be there, but if you use `docker run` to start a new container then that container will not contain the insecure key.\n\nStart a container with `--enable-insecure-key`:\n\n    docker run YOUR_IMAGE /sbin/my_init --enable-insecure-key\n\nFind out the ID of the container that you just ran:\n\n    docker ps\n\nOnce you have the ID, look for its IP address with:\n\n    docker inspect -f \"{{ .NetworkSettings.IPAddress }}\" \u003cID\u003e\n\nNow that you have the IP address, you can use SSH to login to the container, or to execute a command inside it:\n\n    # Download the insecure private key\n    curl -o insecure_key -fSL https://github.com/phusion/baseimage-docker/raw/master/image/services/sshd/keys/insecure_key\n    chmod 600 insecure_key\n\n    # Login to the container\n    ssh -i insecure_key root@\u003cIP address\u003e\n\n    # Running a command inside the container\n    ssh -i insecure_key root@\u003cIP address\u003e echo hello world\n\n\u003ca name=\"enabling_the_insecure_key_permanently\"\u003e\u003c/a\u003e\n#### Enabling the insecure key permanently\n\nIt 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.\n\nEdit your Dockerfile to install the insecure key permanently:\n\n    RUN /usr/sbin/enable_insecure_key\n\nInstructions for logging into the container is the same as in section [Using the insecure key for one container only](#using_the_insecure_key_for_one_container_only).\n\n\u003ca name=\"using_your_own_key\"\u003e\u003c/a\u003e\n#### Using your own key\n\nEdit your Dockerfile to install an SSH public key:\n\n    ## Install an SSH of your choice.\n    COPY your_key.pub /tmp/your_key.pub\n    RUN cat /tmp/your_key.pub \u003e\u003e /root/.ssh/authorized_keys \u0026\u0026 rm -f /tmp/your_key.pub\n\nThen rebuild your image. Once you have that, start a container based on that image:\n\n    docker run your-image-name\n\nFind out the ID of the container that you just ran:\n\n    docker ps\n\nOnce you have the ID, look for its IP address with:\n\n    docker inspect -f \"{{ .NetworkSettings.IPAddress }}\" \u003cID\u003e\n\nNow that you have the IP address, you can use SSH to login to the container, or to execute a command inside it:\n\n    # Login to the container\n    ssh -i /path-to/your_key root@\u003cIP address\u003e\n\n    # Running a command inside the container\n    ssh -i /path-to/your_key root@\u003cIP address\u003e echo hello world\n\n\u003ca name=\"docker_ssh\"\u003e\u003c/a\u003e\n#### The `docker-ssh` tool\n\nLooking up the IP of a container and running an SSH command quickly becomes tedious. Luckily, we provide the `docker-ssh` tool which automates this process. This tool is to be run on the *Docker host*, not inside a Docker container.\n\nFirst, install the tool on the Docker host:\n\n    curl --fail -L -O https://github.com/phusion/baseimage-docker/archive/master.tar.gz \u0026\u0026 \\\n    tar xzf master.tar.gz \u0026\u0026 \\\n    sudo ./baseimage-docker-master/install-tools.sh\n\nThen run the tool as follows to login to a container using SSH:\n\n    docker-ssh YOUR-CONTAINER-ID\n\nYou can lookup `YOUR-CONTAINER-ID` by running `docker ps`.\n\nBy default, `docker-ssh` will open a Bash session. You can also tell it to run a command, and then exit:\n\n    docker-ssh YOUR-CONTAINER-ID echo hello world\n\n\n\u003ca name=\"building\"\u003e\u003c/a\u003e\n## Building the image yourself\n\nIf for whatever reason you want to build the image yourself instead of downloading it from the Docker registry, follow these instructions.\n\nClone this repository:\n\n    git clone https://github.com/phusion/baseimage-docker.git\n    cd baseimage-docker\n\nStart a virtual machine with Docker in it. You can use the Vagrantfile that we've already provided.\n\nFirst, install `vagrant-disksize` plug-in:\n\n    vagrant plugin install vagrant-disksize\n\nThen, start the virtual machine\n\n    vagrant up\n    vagrant ssh\n    cd /vagrant\n\nBuild the image:\n\n    make build\n\nIf you want to call the resulting image something else, pass the NAME variable, like this:\n\n    make build NAME=joe/baseimage\n\nYou can also change the `ubuntu` base-image to `debian` as these distributions are quite similar.\n\n    make build BASE_IMAGE=debian:stretch\n\nThe image will be: `phusion/baseimage-debian-stretch`. Use the `NAME` variable in combination with the `BASE_IMAGE` one to call it `joe/stretch`.\n\n    make build BASE_IMAGE=debian:stretch NAME=joe/stretch\n\nTo verify that the various services are started, when the image is run as a container, add `test` to the end of your make invocations, e.g.:\n\n    make build BASE_IMAGE=debian:stretch NAME=joe/stretch test\n\n\n\u003ca name=\"removing_optional_services\"\u003e\u003c/a\u003e\n### Removing optional services\n\nThe default baseimage-docker installs `syslog-ng`, `cron` and `sshd` services during the build process.\n\nIn case you don't need one or more of these services in your image, you can disable its installation through the `image/buildconfig` that is sourced within `image/system_services.sh`.  Do this at build time by passing a variable in with `--build-arg`  as in `docker build --build-arg DISABLE_SYSLOG=1 image/`, or you may set the variable in `image/Dockerfile` with an ENV setting above the RUN directive.\n\nThese represent build-time configuration, so setting them in the shell env at build-time [will not have any effect](https://github.com/phusion/baseimage-docker/issues/459#issuecomment-439177442).  Setting them in child images' Dockerfiles will also not have any effect.)\n\nYou can also set them directly as shown in the following example, to prevent `sshd` from being installed into your image, set `1` to the `DISABLE_SSH` variable in the `./image/buildconfig` file.\n\n    ### In ./image/buildconfig\n    # ...\n    # Default services\n    # Set 1 to the service you want to disable\n    export DISABLE_SYSLOG=0\n    export DISABLE_SSH=1\n    export DISABLE_CRON=0\n\nThen you can proceed with `make build` command.\n\n\u003ca name=\"ubuntu_2604_rust\"\u003e\u003c/a\u003e\n### Ubuntu 26.04 LTS: Rust Coreutils\n\nUbuntu 26.04 LTS introduced two significant changes compared to earlier Ubuntu releases:\n\n1. **Rust Coreutils (`uutils coreutils`)** — Ubuntu 26.04 ships [uutils coreutils](https://github.com/uutils/coreutils), a Rust-based reimplementation of the GNU Core Utilities (`ls`, `cp`, `mv`, `cat`, etc.), as the default `coreutils` package. This replaces the traditional [GNU Coreutils](https://www.gnu.org/software/coreutils/).\n\n2. **sudo-rs** — Ubuntu 26.04 ships [sudo-rs](https://github.com/trifectatechfoundation/sudo-rs), a memory-safe Rust reimplementation of `sudo`, as the default `sudo` provider. (This is absent in official Docker image)\n\n#### Why this matters\n\n| Concern | Details |\n|---------|---------|\n| **Compatibility** | `uutils coreutils` aims for GNU Coreutils compatibility but may have subtle behavioral differences that can break scripts relying on specific GNU flags or output formats. Test your Dockerfiles and scripts carefully when upgrading to the 26.04 base image. |\n| **Security** | Rust's memory-safety guarantees eliminate whole classes of memory-related vulnerabilities (buffer overflows, use-after-free, etc.). This is generally considered an improvement for security. However, the Rust implementations are newer and have had less real-world exposure than their GNU counterparts. |\n| **Licensing** | `uutils coreutils` and GNU Coreutils are licensed under different terms: `uutils coreutils` uses the **MIT license**, whereas GNU Coreutils is **GPL-3.0**. Users or organizations with specific license requirements should review these changes. |\n| **Maturity** | `uutils coreutils` is a newer project. Some edge cases, rarely-used options, or locale-sensitive behavior may differ from the GNU originals. |\n\n#### Alternatives\n\n**Option 1: Use the Ubuntu 24.04 LTS base image (recommended if you need GNU tooling)**\n\nThe 24.04 \"Noble Numbat\" track is fully supported and ships GNU Coreutils:\n\n```Dockerfile\nFROM phusion/baseimage:noble-1.0.2\n```\n\nOr build the image yourself targeting Ubuntu 24.04:\n\n```bash\nmake build BASE_IMAGE=ubuntu:24.04\n```\n\n**Option 2: Replace Rust Coreutils with GNU Coreutils on Ubuntu 26.04**\n\nWhen building baseimage-docker from source, you can set `INSTALL_GNU_COREUTILS=1` to replace `uutils coreutils` with GNU Coreutils:\n\n```bash\ndocker build --build-arg BASE_IMAGE=ubuntu:26.04 --build-arg INSTALL_GNU_COREUTILS=1 image/\n```\n\nAlternatively, you can install GNU Coreutils in your own Dockerfile that derives from a 26.04-based baseimage by removing `uutils coreutils`:\n\n```Dockerfile\nFROM phusion/baseimage:\u003cubuntu-26.04-version\u003e\n\n# Replace uutils coreutils with GNU Coreutils.\nRUN apt-get update \u0026\u0026 \\\n    apt-get remove -y --allow-remove-essential coreutils-from-uutils \u0026\u0026 \\\n    apt-get clean \u0026\u0026 rm -rf /var/lib/apt/lists/*\n```\n\n\u003ca name=\"conclusion\"\u003e\u003c/a\u003e\n## Conclusion\n\n * Using baseimage-docker? [Tweet about us](https://twitter.com/share) or [follow us on Twitter](https://twitter.com/phusion_nl).\n * Having problems? Want to participate in development? Please post a message at [the discussion forum](https://groups.google.com/d/forum/passenger-docker).\n * Looking for a more complete base image, one that is ideal for Ruby, Python, Node.js and Meteor web apps? Take a look at [passenger-docker](https://github.com/phusion/passenger-docker).\n * Need a helping hand? Phusion also offers [consulting](https://www.phusion.nl/consultancy) on a wide range of topics, including Web Development, UI/UX Research \u0026 Design, Technology Migration and Auditing. \n\n[\u003cimg src=\"https://avatars.githubusercontent.com/u/830588?s=200\u0026v=4\"\u003e](https://www.phusion.nl/)\n\nPlease enjoy baseimage-docker, a product by [Phusion](http://www.phusion.nl/). :-)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fphusion%2Fbaseimage-docker","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fphusion%2Fbaseimage-docker","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fphusion%2Fbaseimage-docker/lists"}