SELinux interfering with Postfix

Posted on .

This is the last post I’ll write about migrating to Fedora and I’ll cover the problem that made me waste more time. I hadn’t run a system with SELinux before and I had trouble finding the source of the problem. Only after searching and reading a lot of web pages, forums and wikis I found a reference to SELinux that clicked in my mind. I’ll bear SELinux in mind for future similar problems.

Long story short, I monitor my hard drives with “smartd” and have it configured to send an email to my user account in case of trouble. I soon realized local mail wasn’t working because Fedora’s minimal installation doesn’t include an MTA by default. From the possible choices in Fedora, I went with Postfix. It’s modern and simple to configure for local mail delivery only. In fact, Fedora’s default configuration file comes prepared exactly for that purpose, with very sane defaults. A quick test confirmed local mail was working, and I forwarded root’s mail to my user account too.

Stage two of the plan involved setting up a $HOME/.forward file for my user that delivered mail to both the local mailbox and an external mail address at my domain. I already had a script prepared for that using some common tools for this situation: “msmtp” to deliver mail to the external address, “formail” (from the procmail package) to slightly modify it before sending it, and “getmail_mbox” (from the getmail package) to deliver it locally unmodified. I’m posting the script below in case you find it useful.

TEMPORARY_FILE="$( mktemp /tmp/mailforward.XXXXXX )"
SUBJECT="$( formail -x Subject -c <"$TEMPORARY_FILE" )"
<"$TEMPORARY_FILE" | formail \
        -i "From: $FROM_ADDRESS" \
        -i "To: $TO_ADDRESS" \
        -i "Subject: [localhost]$SUBJECT" \
        | msmtp -f "$FROM_ADDRESS" "$TO_ADDRESS"
getmail_mbox "$MAILBOX" <"$TEMPORARY_FILE"

That script usually sits as a link named $HOME/bin/mailforward pointing to the real location of the file somewhere else in my home directory (where I keep it under version control), and my .forward file pipes all incoming local mail to it.


I enabled that but surprisingly I noticed I was receiving my local mail only at the local mailbox. SELinux just wasn’t in my mind, but it was preventing the local mail process in Postfix from executing the script, which resided in my $HOME/bin directory as mentioned before. I thought it was a problem with Postfix and wasted more than one hour trying to find out what could be wrong.

There are several possible solutions to the real problem. One is simply disabling SELinux. You can do that by editing /etc/selinux/config and changing SELINUX to the value “disabled”. A reboot is needed, as far as I know, and I don’t remember if running dracut to regenerate the initial RAM disk is needed too.

A second solution is to disable SELinux only for that Postfix process. I read you can do that but I didn’t investigate how to do it.

The third and more elegant solution is simply allowing that specific action that’s currently being denied. I know nothing about SELinux but it’s surprisingly easy to do and well documented. It turns out when SELinux denies permission to do something, it writes a line in /var/log/audit/audit.log describing that event in detail, and that log line is enough for a tool called “audit2allow” to generate a SELinux policy file that can be added to the system allowing the operation, hence the tool name.

Suppose you extract the specific log lines to a file named denied.log and you set on the name “postfixlocal” for the set of rules you want to create. You’d simply run the following.

audit2allow -m postfixlocal <denied.log >postfixlocal.te
semodule -i postfixlocal.pp

The first command creates the SELinux policy, in two forms. A textual form in postfixlocal.te and a “compiled” form in postfixlocal.pp. The second line copies postfixlocal.pp to a special directory and adds the rules in it to the current set of SELinux policies, making it a permanent change.

In my case, the contents of postfixlocal.te were something like this:

module postfixlocal 1.0;

require {
        type user_home_t;
        type home_bin_t;
        type postfix_local_t;
        class lnk_file read;
        class file { execute execute_no_trans };

#============= postfix_local_t ==============
allow postfix_local_t home_bin_t:lnk_file read;
allow postfix_local_t user_home_t:file { execute execute_no_trans };

After that, mail forwarding was working. If SELinux gives me more headaches, I’ll consider disabling it. I don’t think it’s really important for a workstation. But so far that’s the only problem I had with it, and it’s nice to have that extra protection for free. You can simply forget about it. For future weird problems, I’ll remember to check /var/log/audit/audit.log just in case.

Changing the look and feel for GTK apps by hand

Posted on .

If you’re using a lightweight window manager or desktop environment like i3 or fluxbox you may want to tune the appearance of the few GTK or Qt apps you run. They could be Firefox, Thunderbird, Thunar, Wireshark, or whatever. I’ll focus on GTK for now as that’s what affected me. You probably want to change GTK settings without installing or using any application to change them, as they usually bring a myriad of dependencies to your system. What files to edit?

The answer can be easily found in the ArchWiki, the wiki for ArchLinux. It’s a fantastic website with a lot of information, from high level descriptions to the small details you want to know, like in this case. In recent years it has taken the position previously held by the Gentoo wiki, in my opinion.

Before you start, you may want to install a few packages in your system containing icon themes and themes for GTK2 and GTK3. In recent versions, Adwaita is supposed to be the default theme and it looks pretty decent. Also interesting are the Gnome or Tango icons because they’re very complete sets.


After that, changing the appearance of GTK2 apps has been very well documented for years. Basically, create a file named $HOME/.gtkrc-2.0 like the following one:

gtk-font-name = "DejaVu Sans 9"
gtk-icon-theme-name = "gnome"
gtk-theme-name = "Adwaita"


Manually configuring GTK3 is not as well documented usually and not as easy to find with a web search even if it’s not hidden either, but ArchWiki clarifies everything perfectly. You have to create “$XDG_CONFIG_HOME/gtk-3.0/settings.ini”. Usually that translates to ~/.config/gtk-3.0/settings.ini when XDG_CONFIG_HOME is not set. From there you can choose the theme, the icon theme, the fallback icon theme (for icons that are missing in the main theme, I guess) and the font name and size. Example:

gtk-application-prefer-dark-theme = false
gtk-theme-name = Adwaita
gtk-fallback-icon-theme = gnome
gtk-icon-theme-name = Adwaita
gtk-font-name = DejaVu Sans 9

And that’s it. After changing any of those files, restarting apps should be enough for them to pick up the new settings. As you can see, ArchWiki has an equivalent page for Qt too. To know which GTK2 and GTK3 themes are available in your system, apart from checking which packages are installed, look in the /usr/share/themes directory. Theme names are the directory names in there. If a theme has a gtk-2.0 subdirectory, it should be usable for GTK2. If it has a gtk-3.0 subdirectory, it should be usable for GTK3. Icon themes can be found in /usr/share/icons.

Support for 256 colors in Vim under screen (Fedora)

Posted on .

One of the positive surprises in my migration to Fedora was finding out how support for 256-color terminals worked. Some time ago, Fedora created a plan for supporting 256 colors in terminals.

They included support for those applications that needed it in the standard distribution packages, and provided a script in /etc/profile.d that detects if you’re running a shell under a terminal with support for 256 colors, changing the TERM environment variable accordingly. Apart from that, termcap is not present in the system and terminfo has proper terminal information files to support 256 colors.

This prompted me to quickly remove all tricks and specific settings I had in Slackware to enable support for 256 colors. That includes changing TERM from my own $HOME/.profile, and a few lines here and there, like a terminal information line in $HOME/.screenrc. I installed xterm, launched a login session in it and, voila, 256 colors working out of the box.

Then I launched xterm with screen, which I have configured to use a login shell too and, voila again, TERM was automatically set to screen-256color and a quick test confirmed the support was indeed present. So far, so good.

Finally, I launched Vim inside the screen session with my configured 256-colors theme (it’s inkpot, by the way) and it was also working. Strike three. Woot!

But I quickly noticed if I launched Vim in a new screen window, as when running “screen vim”, it was black and white. At this point, if you perform a web search the most common advice is to stick a line with “set t_Co=256” in your $HOME/.vimrc. That line tells Vim that, no matter what, the underlying terminal supports 256 colors. Most people apply that solution because it’s simple and it works, but I don’t recommend it if you can solve the problem properly.

I decided to find out why Vim didn’t think my terminal had support for 256 colors. It took me some time and fiddling to find out, but it turned out to be very simple. When launching “screen vim”, screen by default sets TERM to “screen” unless you specify otherwise in $HOME/.screenrc. Because screen is launching Vim directly in that case, the shell script in /etc/profile.d had no chance to kick in and modify TERM as usual, so TERM was being passed unmodified to Vim. You can easily check it by using “:echo $TERM” from Vim. And if TERM is “screen”, Vim will not attempt to use 256 colors.

Two proper solutions come to my mind. Please comment and share yours if you find better ways.

  1. Changing $HOME/.screenrc so screen sets TERM for new terminal windows to “screen-256color”, using the “term” command. This is not what I did, but it should work.

  2. My preferred alternative: in your login shell inside screen, TERM already has the correct value (screen-256color), so instructing screen to pass along the current TERM value to programs launched in new windows should do the trick. To do that, use “screen -T "$TERM" <command>” when creating a new window.

Choosing the second solution and using it by hand is a pain in the neck, but fortunately I already had a shell function called “launch” that launches programs in a new screen window when inside a screen session, and launches them normally otherwise. That function was the perfect place to insert the -T option without effort.

I’m pasting the function below for those that may find it useful. After defining it, I create aliases for commands I usually like to launch in a new screen window if possible, like Vim, Irssi or man, among others.

# Use "screen" if we are inside a screen session.
launch() {
    if [ -n "$PPID" -a "$( cat /proc/$PPID/comm )" = "screen" ]; then
        screen -T "$TERM" "$@"
alias vim="launch vim"
alias irssi="launch irssi"

Removable volumes under i3

Posted on .

One of the first problems I had with Fedora was to make sure I had a way of easily and graphically mounting and unmounting removable volumes like USB sticks under i3, coming from a minimal installation. Under Slackware, I used Thunar (the file manager from XFCE) for that task. So I went ahead and installed the “thunar” package in Fedora. It turned out to be insufficient. After searching a lot on Google and trying to find out what the problem was exactly, this is the recipe I came up with. None of this would happen if installing a full desktop or the workstation edition, but it’s useful for lightweight and minimalist window managers and other types of environments.

  • First of all, “thunar” will only install the file manager per-se, which is enough to do file managing operations. You need some additional packages to get removable volumes working. Specifically, you’ll need at least “thunar-volman” and “gvfs”. None of those are package requirements.

  • Second and most importantly, you may be using or improvising a quick “xinitrc” script to launch i3 with “startx”. You must not forget to launch i3 in that case through “dbus-launch”. For reference, here’s my “xinitrc” script.

[ -f "$HOME/.Xresources" ] && xrdb -merge "$HOME/.Xresources"
[ -x /usr/bin/nvidia-settings ] && /usr/bin/nvidia-settings -l
exec dbus-launch --exit-with-session i3

Note the above script tries to load the configured settings for the NVIDIA binary driver if present. The important part is the last line and it’s where I lost more time searching.

Completed my transition to Fedora

Posted on .

I finally bit the bullet and moved my main system to Fedora some days ago. So far it’s working perfectly and I’ve been polishing details in the last few days. I hit a couple of rough edges here and there due to aiming for a minimal system with the network installation image for servers, but they’re sorted out. I’ll create a few posts in the next days mostly as notes to myself, to remember how I solved some of those issues.