[{"_1":2,"_152":-5,"_153":-5},"loaderData",{"_3":4,"_13":14,"_20":21,"_131":132},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","routes/_layout.r.$namespace.$reponame",{"_22":23,"_24":-5,"_25":11,"_26":11,"_27":28,"_29":30,"_31":-5,"_32":11,"_33":34,"_83":-5,"_84":85,"_124":-5,"_125":11,"_126":17,"_127":11,"_128":-5,"_129":130},"canonicalUrl","https://hub.docker.com/r/huxy/docker-debian/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","huxy","reponame","docker-debian","cloudBuildSource","isAutobuildsAvailable","repo",{"_35":36,"_37":38,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":50,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":69,"_74":17,"_75":76,"_80":28,"_81":82},"categories",[],"content_types",[39],"image","date_registered","2016-05-28T15:03:00.172892Z","description","Debian base image with init and cron job support. ","is_private","last_updated","2018-03-27T20:52:24.582393Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.container.image.v1+json","name","pull_count",1319,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","credits: nimmis:docker-debian\n\n## Debian Wheezy/Jessie version\n [![Docker Hub; huxy/docker-debian](https://img.shields.io/badge/dockerhub-docker--debian-blue.svg)](https://registry.hub.docker.com/h/huxy/docker-debian)\n\nThis is a docker base image using Debian. It's forked from nimmis:docker-debian but has been further streamlined. \nIt is provided with a working init process, syslog and a cron daemon. \n\n### Why use this image\n\nThe unix process ID 1 is the process to receive the SIGTERM signal when you execute a \n\n\tdocker stop \n\nif the container has the command `CMD [\"bash\"]` then bash process will get the SIGTERM signal and terminate.\nAll other processes running on the system will just stop without the possibility to shutdown correclty\n\n### my_init init script\n\nThe container has a script that handles the init process using the [supervisor system](http://supervisord.org/index.html) to start\nthe daemons to run and also catch signals (SIGTERM) to shutdown all processes started by supervisord. The script is a modification of\nthe script made by Phusion, hence supervisor and not runit. There are also two directories to run scripts before any daemon is started.\n\n#### Run script once /etc/my_runonce\n\nAll executables in this directory are run at start, after completion the script is removed from the directory\n\n#### Run script every start /etc/my_runalways\n\nAll executable in this directory are run at every start of the container, ie, at `docker run` and `docker start`\n\n#### Permanent output to docker log when starting container\n\nEach time the container is started the content of the file /tmp/startup.log is displayed so if your startup scripts generate \nvital information to be shown please add that information to that file. This information can be retrieved anytime by\nexecuting `docker logs `\n\n### cron daemon\n\nThis image provides a running cron daemon. Cronjobs themselves do not automatically import environment varibles. You can either \nimport variables using env >> /etc/environment or sourcing the container_environment.sh file as part of a bash script. \n\n### syslog-ng\n\nNo all services works without a syslog daemon, if you don't have one running those messages is lost in space,\nall messages sent via the syslog daemon is saved in /var/log/syslog\n\n### Docker fixes \n\nAlso there are fixed (besideds the init process) assosiated with running Debian inside a docker container.\n\n### New commands autostarted by supervisord\n\nTo add other processes to run automaticly, add a file ending with .conf in /etc/supervisor/conf.d/ \nwith a layout like this (/etc/supervisor/conf.d/myprogram.conf) \n\n\t[program:myprogram]\n\tcommand=/usr/bin/myprogram\n\n`myprogram` is the name of this process when working with supervisctl.\n\nOutput logs std and error is found in /var/log/supervisor/ and the files begins with the <-stdout|-stderr>superervisor*.log\n\nFor more settings please consult the [manual FOR supervisor](http://supervisord.org/configuration.html#program-x-section-settings)\n\n#### starting commands from /etc/init.d/ or commands that detach with my_service\n\nThe supervisor process assumes that a command that ends has stopped so if the command detach it will try to restart it. To work around this\nproblem I have written an extra command to be used for these commands. First you have to make a normal start/stop command and place it in\nthe /etc/init.d that starts the program with\n\n\t/etc/init.d/command start or\n\tservice command start\n\nand stops with\n\n /etc/init.d/command stop or\n service command stop\n\nConfigure the configure-file (/etc/supervisor/conf.d/myprogram.conf)\n\n\t[program:myprogram]\n\tcommand=/my_service myprogram\n\nThere is an optional parameter, to run a script after a service has start, e.g to run the script /usr/local/bin/postproc.sh av myprogram is started\n\n [program:myprogram]\n command=/my_service myprogram /usr/local/bin/postproc.sh\n\n### Output information to docker logs\n\nThe console output is owned by the my_init process so any output from commands woun't show in the docker log. To send a text from any command, either\nat startup och during run, append the output to the file /var/log/startup.log, e.g sending specific text to log\n\n\techo \"Application is finished\" >> /var/log/startup.log\n\nor output from script\n\n\t/usr/local/bin/myscript >> /var/log/startlog.log\n\n\n\t> docker run -d --name debian nimmis/debian\n\t> docker logs debian\n\t*** open logfile\n\t*** Run files in /etc/my_runonce/\n\t*** Run files in /etc/my_runalways/\n\t*** Running /etc/rc.local...\n\t*** Booting supervisor daemon...\n\t*** Supervisor started as PID 9\n\t2015-08-04 11:34:06,763 CRIT Set uid to user 0\n\t*** Started processes via Supervisor......\n\tcrond RUNNING pid 13, uptime 0:00:04\n\tsyslog-ng RUNNING pid 12, uptime 0:00:04\n\n\t> docker exec debian sh -c 'echo \"Testmessage to log\" >> /var/log/startup.log'\n\t> docker logs debian\n *** open logfile\n *** Run files in /etc/my_runonce/\n *** Run files in /etc/my_runalways/\n *** Running /etc/rc.local...\n *** Booting supervisor daemon...\n *** Supervisor started as PID 9\n 2015-08-04 11:34:06,763 CRIT Set uid to user 0\n *** Started processes via Supervisor......\n crond RUNNING pid 13, uptime 0:00:04\n syslog-ng RUNNING pid 12, uptime 0:00:04\n\n\t*** Log: Testmessage to log\n >\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\n`my_init` provides a solution for all these caveats.\n\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 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.\n\nFor example, here's how you can define an environment variable from your Dockerfile:\n\n RUN echo Apachai Hopachai > /etc/container_environment/MY_NAME\n\nYou can verify that it works, as follows:\n\n $ docker run -t -i /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 any. If you intended on the value having a newline, you should add *another* newline, like this:\n\n RUN echo -e \"Apachai Hopachai\\n\" > /etc/container_environment/MY_NAME\n\n#### Environment variable dumps\n\nWhile 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.\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 makes 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: /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#### 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\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 by 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\n### Installation\n\nThis continer should normaly run as a daemon i.e with the `-d` flag attached\n\n\tdocker run -d huxy/docker-debian\n\nbut if you want to check if all services has been started correctly you can start with the following command\n\n\tdocker run -ti huxy/docker-debian\n\nthe output, if working correctly should be\n\n\tdocker run -ti huxy/docker-debian\n\t*** open logfile\n\t*** Run files in /etc/my_runonce/\n\t*** Run files in /etc/my_runalways/\n\t*** Running /etc/rc.local...\n\t*** Booting supervisor daemon...\n\t*** Supervisor started as PID 11\n\t2015-01-02 10:45:43,750 CRIT Set uid to user 0\n\t*** Started processes via Supervisor......\n\tcrond RUNNING pid 15, uptime 0:00:02\n\tsyslog-ng RUNNING pid 14, uptime 0:00:02\n\npressing a CTRL-C in that window or running `docker stop ` will generate the following output\n\n\t*** Shutting down supervisor daemon (PID 11)...\n\t*** Killing all processes...\n\nyou can the restart that container with \n\n\tdocker start \n\nAccessing the container with a bash shell can be done with\n\n\tdocker exec -ti /bin/bash\n\n\n","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":17,"_78":11,"_79":11},"read","write","admin","user","storage_size",5236770191,"orgData","recentTags",[86],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":95,"_45":113,"_114":89,"_115":28,"_116":51,"_52":117,"_118":119,"_120":104,"_121":113,"_122":61,"_123":17},"content_type","creator",851835,"full_size",74187699,"id",3205664,"images",[96],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":91,"_58":61,"_112":-5},"architecture","amd64","digest","sha256:add3c1f4517e28ca7d5f03924588c8782b09d09df9629b327239b2722e554a3b","features","","last_pulled","2026-09-10T23:15:08.099155975Z","last_pushed","2018-03-27T20:52:25Z","os","linux","os_features","os_version","size","variant","2018-03-27T20:52:24.126455Z","last_updater","last_updater_username","media_type","latest","repository",713151,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_33":133,"_140":141,"_129":150,"_151":11},{"_35":134,"_37":135,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":136,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":137,"_74":17,"_75":139,"_80":28,"_81":82},[],[39],[51],{"_70":11,"_71":138},[73],{"_77":17,"_78":11,"_79":11},"tags",{"_142":59,"_143":-5,"_144":-5,"_145":146},"count","next","previous","results",[147],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":148,"_45":113,"_114":89,"_115":28,"_116":51,"_52":117,"_118":119,"_120":104,"_121":113,"_122":61,"_123":17},[149],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":91,"_58":61,"_112":-5},[],"canDeleteTags","actionData","errors"]

huxy/docker-debian

Tags for huxy/docker-debian