/var/spool/mail/rg3 |/home/rg3/bin/mailforward
Upgraded to Fedora 32 and some local mail tips
Fedora 32 was released a few days ago and I have already upgraded my home computers to it. The upgrade process was as short and smooth as always, so congratulations to everyone involved and also congratulations to everyone behind RPM Fusion, who had their Fedora 32 repositories ready from day 1. From my particular point of view this upgrade required adjusting a few things after installing and some of them are worth mentioning.
mDNS breaks after upgrading
As
explained
in the “Common F32 Bugs” wiki page, there’s a bug present if upgrading from
Fedora 31 to Fedora 32 that will not happen when installing the system from
scratch. If I recall correctly, two packages will fight to modify
/etc/nsswitch.conf
and that will probably result in mDNS being removed from
that file as an option to resolve host names. It will not make much of a
difference to many people but some others may experience problems because of
it. For example, in my case the networked work printer stopped “working” in
the sense that CUPS wasn’t able to properly contact the printer, which led to
confusing situations.
This upgrade bug, as far as I know, was already present when upgrading from
Fedora 30 to Fedora 31. I recommend you to take a look at /etc/nsswitch.conf
just after upgrading and adding the mDNS options if not present, as described
in the wiki.
EarlyOOM is now enabled by default in Fedora
EarlyOOM is a nice thing to have that will try to kill offending processes if you are about to run out of memory, but before actually running out of it so your system will not become unresponsive. It’s one of those relatively simple solutions to a complex problem that will work well for 90% of the cases out there. It prioritizes killing web browsers and other programs known to use a lot of memory while preserving programs that are considered essential for a workstation session if they’re running.
If you didn’t have the package installed before, you may be missing it after
upgrading, so it’s worth taking a look. You could check if the package is
installed with rpm -qa | grep earlyoom
. Once installed, you can verify it’s
running with sudo systemctl status earlyoom
. If not, you can enable the unit
with sudo systemctl enable earlyoom
and start it with sudo systemctl start
earlyoom
.
Periodic TRIM is now enabled by default
Before Fedora 32, I used to mount all my filesystems with the discard
mount
option. This is called continuous TRIM, but it turns out to have some
limitations, like only being able to trim blocks that change from used to free
and having some potential or theoretical security problems with disk
encryption. In this situation, as mentioned in the
Arch
Linux wiki, both
Debian
and
Red
Hat recommend to use periodic trimming if possible and the circumstances allow
it. Periodic trimming is achieved by running fstrim
from time to time, a
utility provided by the util-linux
package, which can be used via a systemd
unit and timer file that are also provided there.
If you were using the discard
mount option before, you can remove it from
/etc/fstab
and the default filesystem mount options, if present, and enable
the fstrim.timer
unit if not enabled.
Some Python 2 packages were purged
With Python 2.x reaching its end-of-life, Fedora has completed the essential
purge of Python 2 packages. Many people will not be too affected by this as
most outstanding Python packages have been ported to Python 3 or have supported
Python 3 for a long time now, but a few of them will be lost. In my case, the
getmail package was removed and I was
using it as part of my mail forwarding script that you can see
here, to receive mail both locally and forwarded to my
main FastMail account when a problem happens in my system and a daemon wants to
send me an email message (think smartd
).
Fortunately, Postfix allows configuring several destinations in ~/.forward
,
one per line, so I changed my mail forwarding script to skip local mail
delivery and added an extra line in my ~/.forward
file, like this:
This will keep both delivery destinations.
Bonus: local mail tip
Related to this, if a daemon generates email output before the network is
completely available, the local delivery part will work but the mail forwarding
part may not, so I consider it essential to be notified of local mail delivery.
As you may know, many shells like Bash will allow you to set a mail spool file
to be checked from time to time using the MAIL
and MAILCHECK
environment
variables, the latter being used to specify the checking period. See man bash
for more details. However, when a new mail message is detected, this will only
print “You have new mail” before the prompt is displayed. If the command you
just ran was a bit verbose it’s easy to miss the line, and it will not be
printed again until you log in or a new mail message arrives.
In my opinion, a superior solution is to check for local mail availability every time the prompt is displayed, and to put something in the prompt itself when local mail is available. This way, the notification will stay in the prompt as long as needed and it’s not as easy to miss, specially if you use colors. You will probably want to use an mbox spool in this case, and remove every message from it after reading them (either deleting them like I do or moving read messages to another mail box).
To achieve what I explained above, I set MAIL to my local mail spool in mbox
format (/var/spool/mail/mbox
) and MAILCHECK to zero to disable periodic
checks using bash. Then, I set PS1 like this:
PS1="$( printf '\001\033[93m\002$( test -s "$MAIL" && printf "[mail] " )\001\033[96m\002\\u@\h:\001\033[95m\002\w\001\033[92m\002\$\001\033[0m\002 ' )" export PS1
As you can see, I use printf as a more portable and shell-independent echo
alternative to generate escape sequences for the prompt colors. The important
part is that, as show above, I run a command in the prompt by generating a
literal “$(…)” in it. This command checks if the mail spool exists and is
not empty, printing [mail]
before the prompt in a different color when it
does. Due to the “$(…)” sequence being included literally in the PS1 value,
this is run every time the prompt is displayed. The notification about pending
mail stays with the prompt until I read and delete the message, making it much
harder to miss.