Postfix: Installing from source on RHEL 5.6

Right now, RHEL 5.6 ships with Postfix 2.3. Which is okay, but its an extremely old version (even with Red Hat's backporting of security fixes) so we decided to go with Postfix 2.8. The major downside of installing from source is that it is a manual process that will have to be repeated every time we see a new Postfix release. Which leads me to the first warning.

Warning #1: If you're going to install a package as complex as Postfix from source code, you really need to take good notes, keep log files from the console and make sure that you understand the process. Some sort of version control for your configuration files should be considered mandatory and you may want to put all of the Postfix binaries and the source / build tree into version control. I strongly suggest the use of FSVS and the repository size on a modern RHEL5 install will generally be in the 500MB to 2GB range (depending on what you include/exclude).

Reference links:

Postfix Announcements

Building Postfix 2.8 on RHEL5 / CentOS 5 from Source

Postfix Installation From Source Code

Getting the source:

Before installing from source, I recommend installing the 2.3 version that ships with RHEL5. This will make sure that the Postfix users and groups are already created and that other directories exist. And it can make configuration easier later.

Since there are no binary RPMs available for Postfix 2.8 combined with the way Postfix includes/excludes major features means that you will almost always build from source. Head over to the postfix.org downloads section and find a mirror close to you.

1. Create a folder where you will keep packages that are built from source. The standard location for files like this is "/usr/local/src" on RHEL5. Different Linux distributions may have alternate locations for source code.
   
2. Download the postfix-2.8.2.tar.gz (cd /usr/local/src ; wget URL)
   
3. Extract the tar.gz file with "tar zxvf filename", this will create a postfix-2.8.xyz directory.
   
4. Warning #2: Never build source as "root". Create an administrator / software install group, assign users to it, then use one of those users to do the compile.
   
5. Change the group ownership of the postfix folder (chgrp -R) to a group of administrators for the system. Change the permissions (chmod -R g+w) so that members of that group can read/write the files.
   

Optional Modules:
 
In order to compile in optional modules like SASL, PostgreSQL support, PCRE (Perl Compatible Regular Expressions), or TLS, you have to configure the Makefile so that the compiler and linker tools know where to look and so that certain constants are set prior to compiling. This is done using the "make makefiles options" command where you supply compiler/linker options and the Makefile is changed to reflect those options.

Note: If you need to include multiple optional modules, then you must create a monolithic "make makefiles" command instead of trying to turn on SASL, then turn on PCRE separately. However, it actually makes a lot of sense for debugging purposes to do test compiles after turning on a single optional module to make sure that you specified the "make makefiles" command properly. After testing the individual module inclusion, you will have to rewrite the commands so that all of the "CCARGS" options are grouped together, then all of the "AUXLIBS" need to be grouped together.

For example, the following command turns on PostgreSQL support in the Postfix source code. The command starting with 'make' should be all one line.

$ cd /usr/local/src/postfix-2.8-xyz
$ make -f Makefile.init makefiles 'CCARGS=-DHAS_PGSQL \
-I/usr/pgsql-9.0/include' \
'AUXLIBS=-L/usr/pgsql-9.0/lib -lpq'

The "-DHAS_PGSQL" is a constant that gets set during compile time that tells the compiler to include any code blocks in the postfix source code tagged with "HAS_PGSQL". (In C code this is done with #ifdef directives.) If this constant is not defined, then postfix will not know how to talk to a PostgreSQL database server.

The "-I/usr/pgsql-9.0/include" section tells the compiler where to find the header files for postfix such as "pg_config.h". If you don't have the PostgreSQL header files installed, then you probably need to install the "postgresql-devel" or "postgresql90-devel" package. If you don't know where the header files are located, try searching the filesystem (using "locate") for "pg_config.h" or "postgres_ext.h".

In the AUXLIBS section, "-L/usr/pgsql-9.0/lib" tells the linker where to find the compiled PostgreSQL libraries such as "libpq.so". These are installed as part of the "-devel" package for PostgreSQL. And their location can be easily found by searching for "libpg.so".
After figuring out where the include modules and libraries are for the optional module, you should do a "make makefiles options" step and then do a test compile by running "make" without any arguments. If this works, make a careful note of the command line options.
Once you have tested out all of the optional modules that you plan on turning on, then you can assemble the final "make makefiles options" command before doing the final compile of Postfix.

The following works on RHEL 5.6 64bit and turns on SASL, PCRE, PostgreSQL and TLS.

$ cd /usr/local/src/postfix-2.8.xyz 

$ make makefiles \
CCARGS='-fPIC -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" \
-DUSE_TLS -DHAS_PCRE -I/usr/local/include -DHAS_PGSQL \
-I/usr/pgsql-9.0/include' \
AUXLIBS='-lssl -lcrypto -L/usr/local/lib -lpcre \
-L/usr/pgsql-9.0/lib -lpq'

$ make

Switch away from Sendmail:

In Unix/Linux, you do not want to have more then one local MTA (mail transfer agent) active at the same time. RHEL5 and CentOS5 both implement the "alternatives" command which lets you switch MTAs. Use "alternatives --display mta" to display the current MTA setting and "alternatives --config mta" to change which MTA takes precedence.

Installation:

First off, make sure that yum will not auto-upgrade postfix. This is done by adding a "exclude=postfix*" line to the /etc/yum.conf file. Any packages that match the space-delimited patterns listed in the "exclude=" will never be touched by yum, even if updated packages are rolled out in one of your RPM repositories.

(See section 6.2 in the Postfix install documents.) If you had previously installed Postfix on the system, then the "postfix" user will have already been created. I suggest doing a quick grep of the /etc/passwd and /etc/group files to verify that the user/group already exists.

Now you will want to either "make install" (new installation) or "make upgrade" (existing installation). You will probably (certainly) have to do this as root. Most of the defaults during the interactive install will be fine. The only default I tend to change is to exclude the README_FILES.

# cd /usr/local/src/postfix-2.8.xyz 
# make install 
install_root: [/] (enter) 
tempdir: [/usr/local/src/postfix-2.8.2] (enter) 
config_directory: [/etc/postfix] (enter) 
command_directory: [/usr/sbin] (enter) 
daemon_directory: [/usr/libexec/postfix] (enter) 
data_directory: [/var/lib/postfix] (enter) 
html_directory: [no] (enter) 
mail_owner: [postfix] (enter) 
mailq_path: [/usr/bin/mailq.postfix] (enter) 
manpage_directory: [/usr/share/man] (enter) 
newaliases_path: [/usr/bin/newaliases.postfix] (enter) 
queue_directory: [/var/spool/postfix] (enter) 
readme_directory: [/usr/share/doc/postfix-2.3.3/README_FILES] no (enter) 
sendmail_path: [/usr/sbin/sendmail.postfix] (enter) 
setgid_group: [postdrop] (enter)

After answering all of the questions, the interactive installer will copy files and create the directories. Now you can move on to configuring Postfix and setting the service to automatically start when the server starts.

SELinux: restorecon not relabeling

Here's a bit of an odd one. Sometimes, restorecon will look like it is not relabeling (refusing to relabel) files/directories. It won't tell you what is going on either and will appear to be silently failing.

What is really going on behind the scenes is that restorecon, by default, even with the -v (verbose) switch is only going to spit out messages about files that it successfully relabels. It will not tell you that a file was looked at, but restorecon did not choose to relabel the file.

Note: This may be something strange with the server's booleans as the hosting company gave us a slightly customized Red Hat Enterprise Linux 5.6 install. We had to bend their arm a bit to let us enable SELinux in enforcing/targeted mode as their support people don't grasp the concept.

To test this, create a folder under /mnt like "test". Then manually relabel it as httpd_sys_content_t using chcon. Now attempt to use restorecon to fix the incorrect label.

# cd /mnt
# mkdir test
# chcon -t httpd_sys_content_t test
# ls -ldZ test
drwxr-xr-x root root user_u:object_r:httpd_sys_content_t test

In order to get restorecon to tell you what is really going on, you have to tell it to be extra verbose with "-vv".

# restorecon -vv test
restorecon: /mnt/test not reset customized by admin to user_u:object_r:httpd_sys_content_t:s0

Ah hah! Now we have some details. Since we now know that restorecon is being blocked due to the file/directory context being "customized", we can use the "-F" switch on restorecon to force the file context label to match the official policy.

# restorecon -vv -F test
restorecon reset /mnt/test context user_u:object_r:httpd_sys_content_t:s0->system_u:object_r:mnt_t:s0
# ls -ldZ test
drwxr-xr-x root root system_u:object_r:mnt_t test

So, if restorecon seems like it is being stubborn and will not relabel your files, try looking at what is going on using the "-vv" and then forcing the issue with "-F". If you want to see what policies might apply to the file in question:

# semanage fcontext -l | grep '/mnt'
/mnt(/[^/]*) symbolic link system_u:object_r:mnt_t:s0
/mnt(/[^/]*)? directory system_u:object_r:mnt_t:s0
/mnt/[^/]*/.* all files <<none>>

LCD monitor prices

Last time I looked at this was back in 2006.  Back then, you could still easily find 4:3 monitors (1280x1024 and 1600x1200) and 16:10 monitors (1680x1050, 1920x1200).  Now the 1920x1080 panels have pretty much pushed everything else out of the market.

Pixel sizes range from 0.248 up to 0.311 mm/pixel for desktop LCD monitors.  That's a range of about 102 ppi for the smaller pixels and 81.7 ppi for the largest pixels, or about a 25% difference.  If the underlying operating system is not setup correctly, that can mean that a font which would be 9pt on the larger screen will appear about the size of a 7.2pt font on the smaller screen.  For older users, that can cause issues with reading text on the web or in documents for long periods.


My personal feel is that anything smaller then 0.285 mm/pixel (89 ppi) is going to be too small unless the user has near-perfect vision.  In the past, that meant if you wanted a 1680x1050 display, you needed to go with a 22" size instead of the 19" size.  For the 19" glass size, the 1440x900 displays were preferable.

(I own both a 19" 1680x1050 and a 22" 1680x1050.  The 22" version is simply a lot easier to deal with long-term because the pixels are about 15% larger.  The 19" monitor gets very little use as a result.)


There are also "large format" LCDs, which are more like TVs then monitors.  Those have pixel sizes starting at around 0.500mm per pixel.  The display area is larger, but the resolutions on some of those are only 1366x768 or 1920x1080, it's just spread over a much larger area.

Amazingly, you can still get 4:3 displays and the SXGA is a popular size with over 60 models at a popular online store.  The smaller 800x600 (SVGA), 1024x768 (XGA) and the larger 1600x1200 (UXGA) displays, however are extremely rare now.  Most of the action has now shifted to HD1080 screens.

Current prices:


SXGA 5:4 1280x1024 (17-19" $100-$300)
WXGA 16:9  1366x768 (18.5" $75-$130)
WXGA+ 16:10 1440x900 (19" $80-$135)
WSXGA+ 16:10 1680x1050 (22" $150-$230)
HD1080 16:9 1920x1080 (21.5-24" $130-$300)
WUXGA 16:10 1920x1200 (24-26" $290-$400)

A lot of the HD1080 screens have a pixel pitch of around 0.276mm (92 ppi) if you get something in the 24" range ($170-$230).  The 27" HD1080 screens have a pixel size of about 0.311mm, but their prices start at $260.  So unless you have the money for the larger glass, you'll probably have to settle for the 0.276mm pixel size, which isn't that far off of 0.285mm.