Asking here before I qualify this as a bug: I’m trying to set up dnf-automatic to maintain security updates and also keep me looped in on available upgrades on a remote system. The documentation (link) says that I can override settings from dnf.conf by adding a [base] section to the configuration file I’m passing to dnf-automatic. However this doesn’t seem to be having any effect.
Furthermore, I have dnf-automatic set up to email me when there’s packages that need installing, which works, however the emails emitted by dnf-automatic contain colored output with escape characters, mangling the message:
The configuration file has INI format consisting of section declaration and name=value options below each on separate line. There are two types of sections in the configuration files: main and repository. Main section defines all global configuration options and should be only one.
What you proposed is not really INI style ?! Can you remove the blanks and test again?
I removed the spaces from the file between the key/value pairs, but dnf-automatic continues to return colored output. The spaces in my example are following the pattern established by the default file at /etc/dnf/automatic.conf which I’ve included below.
[commands]
# What kind of upgrade to perform:
# default = all available upgrades
# security = only the security upgrades
upgrade_type = default
random_sleep = 0
# Maximum time in seconds to wait until the system is on-line and able to
# connect to remote repositories.
network_online_timeout = 60
# To just receive updates use dnf-automatic-notifyonly.timer
# Whether updates should be downloaded when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
download_updates = yes
# Whether updates should be applied when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
apply_updates = no
# When the system should reboot following upgrades:
# never = don't reboot after upgrades
# when-changed = reboot after any changes
# when-needed = reboot when necessary to apply changes
reboot = never
# The command that is run to trigger a system reboot.
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"
[emitters]
# Name to use for this system in messages that are emitted. Default is the
# hostname.
# system_name = my-host
# How to send messages. Valid options are stdio, email and motd. If
# emit_via includes stdio, messages will be sent to stdout; this is useful
# to have cron send the messages. If emit_via includes email, this
# program will send email itself according to the configured options.
# If emit_via includes motd, /etc/motd file will have the messages. if
# emit_via includes command_email, then messages will be send via a shell
# command compatible with sendmail.
# Default is email,stdio.
# If emit_via is None or left blank, no messages will be sent.
emit_via = stdio
[email]
# The address to send email messages from.
email_from = root@example.com
# List of addresses to send messages to.
email_to = root
# Name of the host to connect to to send email messages.
email_host = localhost
[command]
# The shell command to execute. This is a Python format string, as used in
# str.format(). The format function will pass a shell-quoted argument called
# `body`.
# command_format = "cat"
# The contents of stdin to pass to the command. It is a format string with the
# same arguments as `command_format`.
# stdin_format = "{body}"
[command_email]
# The shell command to use to send email. This is a Python format string,
# as used in str.format(). The format function will pass shell-quoted arguments
# called body, subject, email_from, email_to.
# command_format = "mail -Ssendwait -s {subject} -r {email_from} {email_to}"
# The contents of stdin to pass to the command. It is a format string with the
# same arguments as `command_format`.
# stdin_format = "{body}"
# The address to send email messages from.
email_from = root@example.com
# List of addresses to send messages to.
email_to = root
[base]
# This section overrides dnf.conf
# Use this to filter DNF core messages
debuglevel = 1
Additionally, dnf-automatic doesn’t throw any errors when parsing the configuration, leading me to assume that the configuration is indeed valid. Even more puzzling, if I add other options to the configuration file under the [base] section, like for example
excludepkgs=pkg*
then dnf will respect that option when called by dnf-automatic. Even if I override the different colors manually, for instance color_list_available_downgrade=yellow, those options are respected, it’s just the global color=never option to disable colored output that doesn’t have any effect.
Has this ever been resolved? This is the only thread I can find this issue even mentioned for email output.
color = never is set in dnf (and works at cli) and tried to set in automatic.conf as color = never or color=never. However, email is still sent with dnf-automatic with the color codes in it. It is very annoying.
Hi guys, I stumbled upon this topic while analysing kinda related dnf-automaticissue. There is a bug which results in the color option not being applied when using the dnf-automatic (it works with the dnf though). I’ve created a PR to fix this, so hopefully we will get it into the Fedora soon.
Just for curiosity, did someone check this in DNF5. As in F41 default will be dnf5 it would be good if someone checks if this also works. In case it would be a regression.
