])
pkgs that look like they should be upgraded: git
git-man
...
All upgrades installed
InstCount=0 DelCount=0 BrokenCount=0
Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2019-12-24 17:32:55
root@osestaging1-discourse-ose:/var/www/discourse#
```
The git version that was updated in the above `unattended-upgrades` run was `git (1:2.20.1-2+deb10u1)`. I ran this test today (2019-12-24), but the security upgrade had been available to Debian Buster (the OS on which the Discourse docker image is built) for two weeks (since 2019-12-10)!
This is actually a pretty serious upgrade that fixes several vulnerabilities, including two vectors for Remote Code Execution. More info is available at the Debian Security Advisory 4581-1
- [I Challenge Thee](https://www.debian.org/security/2019/dsa-4581)
But git is just an example I happened to stumble on. It’s extremely concerning if the Discourse docker container doesn’t (by default) actually apply security-related patches to its OS.
Is this a bug? Or was this an intentional decision by the Discourse team? Or is this just the default in-lieu of a feature request to enable `unattended-upgrades` on the Discourse docker container?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 24, 2019, 6:07pm UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/4 "2019-12-24T18:07:26Z")
My guess is that it’s off on purpose as it might break something, and the image itself is updated when a serious security issue is found.
You can enable it if you want, just enter the container.
---
### Author:  [@maltfield](https://meta.discourse.org/u/maltfield)
#### Post date: [December 24, 2019, 6:12pm UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/5 "2019-12-24T18:12:10Z")
Actually, I just realized that Discourse’s docker image is setup to use `runit`. Is `systemd` even installed on the Discourse docker container?
My guess is not having `systemd` installed is what’s breaking `unattended-upgrades`.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 24, 2019, 7:53pm UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/6 "2019-12-24T19:53:52Z")
Sounds right. Some people really don’t like systemd. So you can either trust that the base container gets updated regularly by people running a large team of professionals that depends on it, or you can do it some other way yourself and hope that you don’t break anything.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [December 24, 2019, 9:06pm UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/7 "2019-12-24T21:06:40Z")
> [@maltfield](#):
>
> But what about the Discourse docker container? Does _it_ use `unattended-upgrades` ?
No it doesn’t and we don’t plan to make it use. The recommendation is to keep your host OS updated with the latest security patches.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [December 24, 2019, 11:22pm UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/8 "2019-12-24T23:22:01Z")
> [@pfaffman](#):
>
> So you can either trust that the base container gets updated regularly by people running a large team of professionals that depends on it,
Which, for the record, it is.
---
### Author:  [@maltfield](https://meta.discourse.org/u/maltfield)
#### Post date: [April 23, 2020, 10:26am UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/9 "2020-04-23T10:26:11Z")
fyi, I fixed the broken `unattended-upgrades` install (which doesn’t actually run without systemd on the Discourse docker container) by triggering it to run via a cron job.
I created the following yaml template file in my `/var/discourse/templates/` dir to create the necessary cron job (note that it also has a command to [fix a bug with cron](https://meta.discourse.org/t/cron-in-docker-container-cannot-make-remove-an-entry-for-the-specified-session/148969/2) shipped in the Debian-based Discourse docker image):
```plaintext
cat << EOF > /var/discourse/templates/unattended-upgrades.template.yml
run:
- file:
path: /etc/cron.d/unattended-upgrades
contents: |+
################################################################################
# File: /etc/cron.d/unattended-upgrades
# Version: 0.2
# Purpose: run unattended-upgrades in lieu of systemd. For more info see
# * https://wiki.opensourceecology.org/wiki/Discourse
# * https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/3
# Author: Michael Altfield
# Created: 2020-03-23
# Updated: 2020-04-23
################################################################################
20 04 * * * root /usr/bin/nice /usr/bin/unattended-upgrades --debug
- exec: /bin/echo -e "\n" >> /etc/cron.d/unattended-upgrades
# fix the Docker cron bug https://stackoverflow.com/questions/43323754/cannot-make-remove-an-entry-for-the-specified-session-cron
- exec: /bin/sed --in-place=.\`date "+%Y%m%d_%H%M%S"\` 's%^\([^#]*\)\(session\s\+required\s\+pam_loginuid\.so\)$%\1#\2%' /etc/pam.d/cron
EOF
```
To enable the above template file, you have to add it to your list of `templates` in your app’s yaml file. For example,
```plaintext
[root@osestaging1 discourse]# head -n20 /var/discourse/containers/app.yml
## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed
templates:
- "templates/unattended-upgrades.template.yml"
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
# - "templates/web.socketed.template.yml"
- "templates/web.modsecurity.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
[root@osestaging1 discourse]#
```
---
### Author:  [@tormod](https://meta.discourse.org/u/tormod)
#### Post date: [May 23, 2020, 3:36pm UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/10 "2020-05-23T15:36:29Z")
It seems that it is enabled on a fresh Discourse docker image (running Debian 10). It is launched through runit → cron → /etc/cron.daily/apt-compat → /usr/lib/apt/apt.systemd.daily
It was also running on a one-year-old Ubuntu 16-based docker image (based on discourse/base:2.0.20190321-0122), I am pretty sure without any customization.
---
### Author:  [@maltfield](https://meta.discourse.org/u/maltfield)
#### Post date: [September 22, 2020, 7:46am UTC](https://meta.discourse.org/t/does-discourse-container-use-unattended-upgrades/136296/11 "2020-09-22T07:46:00Z")
> [@tormod](#):
>
> It is launched through runit → cron → /etc/cron.daily/apt-compat → /usr/lib/apt/apt.systemd.daily
systemd isn’t installed, so it never actually runs.