It drove me crazy.
Yes, I am competent to make it work for most things, but some issues were just too much trouble. Keep in mind that when RHEL 6 (followed by the clones like CentOS) came out, it was capable of handling XP hardware and some early Vista stuff. Try installing it as a desktop on a Win7 machine and you will suffer. Things keep breaking because the drivers don’t match the hardware quite well enough.
The desktop machine was given to me needing repair from a law office that had closed. Turns out it was still under warranty but only to a company no longer in existence. It came with Win7 Pro but I never could get along with that once I fixed it. So I’ve run several different things, but I keep coming back to Debian Wheezy because it’s the most sane. For sure CentOS 6 was just not up to it.
So I’ve finished the tutorial and it will be my next book in a few days. It’s just fine for SOHO stuff on older XP machines, but I am not doing SOHO stuff, nor do I have any old machines like that. And CentOS is pretty corporate straight-laced and no fun.
This thing is pretty low spec, starting with a dual-core 1.3Ghz processor. It comes with Win8 and I would personally never tolerate that on any of my computers. While I am capable of helping my clients set theirs up and to fix a few minor issues, Win8 seems to be the final ultimate breaking point for me. I even tried downgrading to the Win7, as that would have been tolerable to me, but the drivers were simply not capable of sustaining life on this cranky hardware.
Linux to the rescue: I tried four distros. Those that should have booted in UEFI could not get past hardware detection. They all simply hung and did nothing. And frankly, all the 64-bit versions were noticeably slower than the 32-bit version of the same distro, so there was no reason to stay with 64. Also, please note I refuse to use any DE except XFCE.
Debian Wheezy: You’ll need the RealTek firmware package on a thumb drive before you start, and it has to be in the top directory. The installer will ask for it; with that, everything works out of the box. The stock
radeon drivers produces really slow display changes on some items, so you’ll want the Catalyst driver (AKA fglrx). However, you won’t be able drop into console mode. With Wheezy, the system seems overall snappy enough, but when you run stuff like Iceweasel, you’ll notice it bogs down a lot. It’s no better if you build Firefox optimized from source or install the official tarball. Seamonkey isn’t quite as bad.
Xubuntu 12.04: Everything installs nicely, but there has been a long-standing issue with the rtl-8188ce wifi chipset. Canonical elected not to fix it, but you can install the kernel backports for the wifi. At this writing the specific package name is
linux-backports-modules-cw-3.8-precise-generic-pae. Otherwise, your wifi will never stay connected. (No, I don’t mess with anything except LTS releases.) The automatically offered Catalyst driver works fine and is better integrated; I got a console. You have to chase down the instructions for re-enabling hibernate. Overall, it runs somewhat slower than Debian Wheezy.
OpenSUSE 13.1: This is the winner. Everything works out of the box. The built-in
radeon driver is much better these days and I never felt the need for Catalyst. It’s very snappy, so that dropping in and out of hibernate is relatively quick. Naturally, SUSE is very observant of the legal niceties about the font rendering patents, so you’ll need to hunt down the muzlocker repo and procedure. At this writing, there are no packages for 13.1, but the Factory branch works well enough. For now, this one is the keeper. It’s also the only distro where Midori as supplied was worth using, which is pretty light and quick against the other standard web browsers. One other oddity: There is a USB port on the left side of the machine on which the other distros kept choking, but SUSE handles it just fine.
I tested Scientific Linux 6 (latest release) and it would run okay, but fared poorly overall. That is, the screen paints were painfully slow with the bundled
radeon driver but if you use the fglrx supplied by ElRepo it tends to lock up the GUI quickly and often, requiring a hard reset. I didn’t try the build-your-own route using the download from AMD/ATI. I would wait until RHEL 7 comes out and either use that or wait for the clones to build their free versions.
I horse-traded for this laptop; it’s not something I would go out and buy even if I had the money. The only serious redeeming quality is the battery life, easily hitting 5 hours without recharging running on any Linux I tested.
Update: Perhaps I could waste a lot of time listing all the things about SUSE that require me to relearn just about everything I do on a daily basis, but after trying to get used to, I decided it simply wasn’t worth it. Now, while Xubuntu 13.10 does run as fast on this thing as SUSE did, it’s just too darned buggy and fixes for some important stuff aren’t going to happen. I checked the buglist of known issues and the attitude seems to be lack of interest on the things that bother me most. I’ll go back to Xubuntu 12.04 because I know it works and it’s less work than just about anything else.
Update 2:Xubuntu choked, refusing to use the PAE kernel and thus losing me a half-gigabyte of RAM. Dear readers, I have been slapped upside the head by learning some things I had missed previously. It changes everything. I found out the reason there is no console when running Wheezy is because of a package I needed called “firmware-linux-nonfree” — something not easily discovered when chasing Debian information. A ton of drivers, but in the typical Debian politics, has to be separate. It includes some firmware for Radeon. Once installed, I had no need for the fglrx driver. This means I’ll also have to rewrite the draft of my book on Debian for newbies.
Debian Wheezy is the winner.
On CentOS 6, the GNOME Dictionary is broken.
Apparently, I’m not the only one who has noticed this. Unfortunately, I’ve not seen where anyone posted a proper fix. It worked fine in both RHEL 6 and SL 6 on this same machine.
On the other hand, I never did like it that well. The good news is the best fix is to ignore GNOME Dictionary and replace it. That replacement would be Artha. You can get the SRPM here. Just scan down for it in alphabetical order, or use the “Find” function in your browser.
When building the RPM, you’ll need to add a couple of tools not likely already installed on your system, but they are all available from the standard Yum repositories for CentOS.
Once built, on the initial start, you’ll be informed of the default keyboard shortcut. Then it will simply load and run in your notification area. Double-click any word in any application, hit the shortcut (defaults to CTRL-ALT-W) and the dictionary window opens with the appropriate information. It takes very little of your computer resources, so I recommend leaving it running.
This is a great tool, and is what GNOME Dictionary should have been.
We all know Red Hat Enterprise Linux (RHEL) is the basis for both CentOS and Scientific Linux (SL). The differences are largely cosmetic from the user’s point of view, in which the clones are legally required to change only the artwork and remove the Red Hat logos. There are differences in how each clone project goes about building the product from common sources, but I doubt you’ll find any difference in how they behave. Everything I’ve written about RHEL and SL applies to CentOS. All I’m doing here is summing up the combined notes of how we get from putting in that install DVD to a usable system.
This is what I did installing CentOS 6.2 on a Dell Inspiron 1525.
1. Install options: I chose the minimal graphics driver, because this system has Intel graphics. The Linux kernel used by Red Hat has a bug with some Intel graphics framebuffer hardware (intelfb). It’s easy to work around and fix it later. Most of the other options should be obvious. When in doubt, I typically take the defaults offered.
2. However, I don’t like dual booting two or more OSes, so I chose to “Use all space” for the disk options. When it came up, I chose the standard “Desktop” profile without trying to adjust the package selection.
3. When the installation is finished, it will kick out the DVD and wait for you to press “Reboot.” In the post-install configuration, you should simply pay attention to the options and choose what fits your needs. For example, I chose to use NTP for the system clock, and made sure to un-check the UTC box in the lower left corner.
4. After logging in, I immediately click on the Networking icon on the upper right toolbar and set up the option to connect automatically. Then I open the Terminal under Applications > System Tools, and “su” to root. This is the time to fix the Intel driver issue. I also run:
yum groupinstall "Development tools"
Almost every time I update post-install, I receive a kernel update, so this is where I reboot.
5. Upon logging in again, I add a few select packages. You can do this through the System > Administration > Add/Remove Software application or from the commandline as root:
yum install xterm bitmap-fixed-fonts aspell alacarte gnome-games gnome-games-extra gimp units vim-X11 elinks dos2unix unix2dos
The first two items after “install” go together. In particular, you might want
alacarte, which allows the user to edit the GNOME menu system. GNOME Games comes in two packages. I use GIMP from time to time, and whomever packages Elinks has recently begun tracking the original project itself; good text browser but requires a bit of work getting the options as you might like them. Units is a CLI conversion calculator between various types of measures, with a long list of metric, English, etc., units. Remember to hit CTRL-C when you are done to kill it. The rest you can figure out for yourself if you need them. Also, be aware you’ll need to chase down Aspell’s English language package on your own. I have no idea why it’s not in RHEL’s package repositories, but I built it from SRPM, pulled from Fedora 13′s repositories.
6. This is the time to do the first half of font fixing. After adding my favorite TTFs to my
~/.fonts folder (you’ll likely have to create it), then as root, fix the fonts by changing the settings for the whole system. Finally, I rebuild the Freetype libraries. That means chasing down the SRPM, and both SL and CentOS simply point you to the upstream RHEL ones. However, I’ve changed a few details from my previous tutorial: I use Yum –
yum localinstall nogpgcheck freetype-2.3.11-6.el6.8.i686 freetype-devel-2.3.11-6.el6.8.i686
Logout, hit CTRL-BKSP and restart the X server with the new Freetype libs. Fonts will look much, much better. Now’s the time to adjust the appearance of your desktop and set your preferred default fonts. I’ve always imported the Dirty-Ice GTK2 look in the process. You can probably find a copy using your favorite search engine.
7. Next comes the JDK replacement with Oracle’s latest 1.6 series (1.7 fails with OpenOffice and LibreOffice), because it’s much faster than the bundled OpenJDK package. I also grab the latest
fuse-ntfs-3g from RepoForge. That would be the one for “el6″ in this case.
8. After testing one more time to be sure, I cannot recommend Dag Wieers’ RepoForge because too many of the packages are way out of date, and they still exclude Mikmod, which I use. So if you want full multimedia and other advanced third party goodies, the best remains ATrpms. However, compared to my original tutorial, I typically leave off the Mplayer and extra codecs until I run into something which simply won’t work after adding all the extra goodies for Gstreamer. However, nothing in Linux land compares to using FFmpeg for converting audio and video files.
9. However, for Broadcom wifi, I don’t trust ATrpms to keep up when the kernel gets upgraded. It’s best to simply grab the zipped driver package direct from Broadcom. The instructions bundled in the driver are pretty good, but the point is whenever the kernel is upgraded, you simply rebuild at your convenience and re-install the module. Check the link periodically to see if they have updated to a later version; the latest is from October last year.
10. I prefer the latest versions of Joe’s editor and Lynx web browser. You can chase them down from the latest Fedora SRPMs; they’ve always built fine with RPMbuild. As of this writing, they can be found here. As time goes on, you can go there, jump up the “Parent Directory” links a couple of layers and back down into later releases of Fedora SRPMs. I also do the same with Alpine because I really prefer doing email from the commandline. You can learn how to configure Alpine here.
10. The last two items is adding Bleachbit and whatever browsers you might like. I seldom use Firefox for anything these days, but prefer Chrome and Opera. You can find them if you like them.
11. I also fix Vim. For some strange reason, on CentOS Vim also does not honor my
textwidth setting unless I put that on its own
set line in my
12. The last thing I do is turn off a few services I know I won’t use on my laptop:
You’ll find this in the menu under System > Administration > Services. Make sure the items you don’t need have a red dot to the left of them. Be very careful! You could easily cripple your system by accident by turning off something basic and essential, such as the keyboard driver.
At some point you may be requested to put in some password for GNOME Keyring. It’s just your login password, so don’t panic.
Update: Recent issue with updating ffmpeg from ATrpms. When you try to update via Yum, or via the Update Manager (that bright orange icon in the notification area), you’ll get an error something like this:
Error: Package: libavcodec53-0.10-54.el6.i686 (atrpms)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Here is the simplest and quickest solution; just copy and paste as a single line into any terminal window:
yum update libvpx - --enablerepo=atrpms-testing --disableplugin=*
Yes, this will change one of the core libraries from the upstream provider (RHEL). It shouldn’t break anything, but it could. You be the judge; it’s part of the risk of using any external Yum repo.
The Latitude will not be available. I’ll be testing CentOS on my Inspiron 1525. I am downloading via Bittorrent as I type this (and sampling the experience of dialup speeds for my browser in the process). Opera’s built-in torrent handler is pretty cool.
Review of procedures, etc., in a few days.
It’s not that I didn’t like running Debian Squeeze on my laptop, it’s that there was no reason to ever use the laptop since my desktop was identical. I noticed Scientific Linux (SL) was close to releasing their 6.0 and decided to try the latest release candidate. Unlike CentOS, SL runs a beta test program and it is now quite usable.
You can review the series on RHEL 6 for the Clueless (now in a static archive linked here) for most of the details. I’m sure most of that will also apply when CentOS 6.0 comes out later.
There are several other differences between CentOS and SL. It appears CentOS has a much larger user base, and the mailing list archives indicate a rather different kind of user. SL draws the Fermilab-CERN crowd, naturally, as that’s where it’s produced. The users of CentOS include a much larger group of rowdies, so to speak. I sensed the developers were being hounded by impatient folks, whereas the SL lists are much more calm about these things. On the other hand, CentOS developers keep more of their discussions in private, and don’t take time to post detailed descriptions of their progress toward each release. SL has their very public whiteboard, which is a copy of the project leader’s literal whiteboard kept in his office. There is also a nice listing of problem RPMs and how they went about getting past the build failures. Thus, perhaps it’s simply sane for the CentOS devs to avoid wasting time responding to every passing anxious user, whereas the SL folks don’t seem the face much of that.
You’ll be happy to know the ATrpm repository covers SL, as well. However, you’ll have to edit your YUM repo file once you install the ATrpm repo. Here is what I had to make mine look like:
This will get you all those nice tweaked codecs and packages for multimedia playback. Please note, Adobe now has it’s own YUM repo for the Flashplayer plugin. When you go to Adobe’s download page, you’ll get the option to select the YUM package. This allows updating the Flashplayer directly and automatically.
On the issue of fixing the bytecode hinting in the Freetype library, I noticed the SL repo is out of date compared to what is installed from the DVD. I had to get my SRPM directly from the RHEL respository. It still works out fine.
Overall I’m very pleased with how well it works like RHEL, but free and tweaked just a bit to make it easier to use. I heartily recommend Scientific Linux as a good clone of RHEL. The DVD required I select the minimal video driver, but it all worked nicely and I didn’t have to do anything to make suspend and hibernate work. SL has added a few more options for the touchpad to the standard GNOME mouse config dialog. This is typical of the enhancements you’ll find.
Today Red Hat issued a security update for Open Office on all three versions which had it (4, 5, & 6). If you don’t have access to RHN, you would be crazy to try building it from the SRPM. Frankly, you’d be crazy for not updating to the latest version now supplied by Libre Office.
(Update: Please note the advice offered below in the comments, and avoid using the latest version of Java 1.7. The latest updated version of 1.6 is still available and is preferred.)
Get it here. You’ll need both the main package and the help files. Open a Terminal window and login as root. Place them in a convenient directory. I generally use
/home/bkup for stuff like this. When you install RHEL with the default configuration, it gives most of the disk space to a partition for
home, where all the user directories are kept. Unless you have a half-terabyte or more, the other primary partition isn’t big enough for too much storage. Remove your old version of Open Office if you have it:
yum remove openoffice*
You’ll be shown a list of files being deleted. Do it. So you get it in that directory where you moved those two files, and you’ll need to open them up:
tar -xvfz LibO_3.3.0_Linux_x86_install-rpm_en-US.tar.gz
tar -xvfz LibO_3.3.0_Linux_x86_helppack-rpm_en-US.tar.gz
This will create two folders with matching long names on them. Start with the installer. Move down into the folder and you’ll see:
readmes RPMS update
You can drop down into the
readmes and take a look at the file there, but I’ll save you some time. Drop down into the
RPMS folder. The “update” is a script we won’t be using. Inside the RPMS folder is a whole bunch of oddly named RPMs. We’ll keep this simple. In order to install these packages, which did not come from Red Hat, we’ll need to tell Yum to skip the signature checks, because we already know we can trust the good folks at Libre Office.
yum install --nogpgcheck *.rpm
On the the Linux command line, that asterisk is a symbol which means “match all” and we qualify that with the “.rpm” so it matches all the RPMs in the current folder. Yum will run through all the RPMs and check that they match up, then ask you to make sure you want to do it. You do, so hit “y”. Now move into the folder which holds the menu integration RPMs:
Here, we need the package which integrates with the Red Hat menu system for your desktop, and we’ll tell Yum the same thing about that package, not checking the signature:
yum install --nogpgcheck libreoffice3.3-redhat-menus-3.3-6.noarch.rpm
Move up three layers, then down into the other folder with the RPMs:
We need a similar incantation for this single RPM as we did the others:
yum install --nogpgcheck *.rpm
You’re almost done. I’m not sure where it came from, but there is an odd glitch in how this actually configures the menu. In mine, at least, I got duplicate entries, with one set for the new Libre Office 3.3, and another for the old Open Office 3.2. This stuff happens from time to time, and it’s why I advised adding the Alacarte menu editor in my installation tutorial.
Right-click on your “Applications” menu and select “Edit Menus”. In the window which opens, on the left pane select “Office” and you’ll see the list on the right pane. For all the items labeled “OpenOffice.org” simply click to remove the check marks. They are the ones missing the icons. This will hide them as menu entries. All that’s left is the newly installed LibreOffice stuff. You’re done. Enjoy.
Because RHEL is essentialy an industrial grade commercial product, you’d have to expect it can run more types of server than most people would ever need.
We covered the Samba server in a previous lesson as the most common need for small or home operations. As long as you have to accommodate Windows clients, Samba is the simplest way to go, since even Linux clients can use it. However, if all you need to worry about is sharing files with other Linux/Unix clients, the NFS (network file system) is really better. It’s not covered in the Deployment Guide, and the only simplified guide I’ve seen is this one. There really isn’t that much to it. Windows can use NFS, and Microsoft offers the software to use it, but they assume you are migrating away from Unix, and will demand some information from you. At that, it only works on the Pro versions of their OS. You could also search for some third party software packages, but it I don’t know whom I would trust for that.
The majority of my computer ministry clients have no use for an FTP server. On top of that, the RHEL Deployment Guide hardly mentions it. However there are already some good, short tutorials on how to get it working. This one is fairly generic, but rather complete. And here’s one which covers the SELinux aspects of configuring your FTP server. RHEL uses the Vsftp (Very Secure FTP) server. The CentOS HOWTO Wiki on Vsftp actually hands it to you with scripts to set it all up. It centers on using a feature called “chroot” — a sort of controlled sandbox which makes it exceedingly difficult for those using your FTP server having any chance of cracking the machine itself. I recommend the TSL script for setup.
Much more popular is the Apache webserver. The Deployment Guide covers it, but in a good bit more detail than you might find useful. Again, some enterprising writers have already given us a head start. This one is short and sweet, covering the bare essentials. Then there is this one which addresses the details of SELinux protections, how to configure for a server which hosts multiple sites, and much more. If you need to enable the secure protocol (https) I really like this one from CentOS Wiki.
But if you are going to go that far, you should consider using the well known LAMP stack (Linux, Apache, MySQL and PHP). It’s almost trivial adding the MySQL server and PHP. What isn’t trivial is the knowledge necessary to use them. Here is a good generic setup tutorial, but be aware a few of the package names may have changed for RHEL 6. However, cnce you get Webmin installed, you are limited only by what you know about webmaster and system administrator tasks in general. It’s the easiest way to go for the clueless, with some documentation, and for more than just the LAMP server itself. However, I recommend you download the Webmin Manual (PDF). It can make a wide range of system administration tasks much simpler, and people are running entire ISPs this way.
Of course, the big thing with RHEL 6 is the kernel-base virtual machine (KVM), the computer within a computer. It requires some rather powerful hardware. Frankly, I can’t imagine needing it for my clients or myself. Still, the Techtopia series starting with section 33, gives you the shortest path, I think, using Windows 7 as the client OS. You can always plow through the Deployment Guide, of course, but it’s harder to follow. It’s written for well-trained technicians with some experience in that sort of heavy duty server work.
One of the most useful things RHEL can do in an organization is serve as the firewalled gateway. This can be easily combined with other tasks on the same machine. Naturally, it requires your RHEL box to have at least two hardware ports, since one becomes the internal trusted interface, and the other an untrusted interface. Then a standard multi-port LAN switch can feed into the RHEL box if you have a significant number of computers. This is well covered in the Deployment Guide, but you probably would find this page a lot simpler. To do anything special requires you understand firewalls and policies. There simply is no shortcut there, however, the defaults configurable from the RHEL GUI firewall manager are pretty good for most uses.
As with the mail server, most of this is pretty hard to test from a home LAN with a broadband connection. If your ISP permits running a server, but can’t offer a static IP address, you should consider connecting through an external DNS service such as OpenDNS, DynDNS, and number of other free services. They keep track of resolving your domain name to whatever IP address you have at the time. It’s pretty rare when you’ll need to run your own DNS service internally, except perhaps a simple name caching. However, even that is becoming almost pointless, as these external free services are quite reliable compared to even the larger broadband ISPs.
The possibilities of RHEL 6 will quickly outrun all but the most obscure server needs.
In trying to keep RHEL 6 up to date without support, I am sometimes both amazed and disappointed at the way Red Hat keeps some of the SRPMs out of reach.
The RHSA notice presents a minor security warning about the Hplip libraries. But if you attempt to build from the SRPM, you’ll find a dependency almost impossible to fulfill. In order to build Hplip, you need
sane-backends-devel. But that one is not normally installed, and if you lose your access to RHN, you’ll have to build it from source. That, in turn has a dependency on
There is no source for that. I scoured the freely accessible repositories in both RHEL (including the Beta sources) and Fedora, and there is nothing close. Remember, a partial requirement is keeping the versions consistent. The version for
gphoto2 is 2.4.7-4. The closest you’ll get is the FC12 package, which is 2.4.7-1. Even if you cheat and edit the SPEC file in the SRPM to call itself “-4″ it won’t built the devel package. I have no idea why it’s excluded, but it won’t produce. Thus, you end up with something totally orphaned here. Then you end up wondering how the Red Hat developers built it themselves in the first place, except they simply aren’t being honest in releasing all the applicable SRPMs.
The CentOS developers noted this often enough in their developers mailing list. There are times you simply can’t replicate Red Hat’s work because they hold stuff back. I lack their expertise in recreating the missing SRPMs from sources, chasing down the peculiar collection of patches, etc. At any rate, the work-around is simply installing the
sane-backends-devel RPM from the Beta repositories, because it’s the same version. But I’m still left without any source for
gphoto2. I can get the dependency for it (
libgphoto2) but not the item itself.
If you are running RHEL, you are already running a mail server. It’s installed by default and setup to run. Of course, it only delivers mail locally, and only from sources within your own machine. Right now, there are no sources, so there is no mail. But the server is running.
The original Unix way of things was to use the mail server as the primary internal message system. RHEL is old fashioned in this respect, though by default, nothing is turned on which sends any messages to the root account. If you want to learn more about what’s going on in your system, install the logwatch package with Yum and you’ll start getting daily email messages to your root account with standard notifications of newly installed packages, who logged in when, and other significant events most system administrators track. You can adjust what sorts of things logwatch tells you about, but the defaults are pretty good.
The problem is, you’d have to figure out how to read that mail. By default the simplest way to do that is to install something called Mutt — as you might expect, the package name is in lower case. Yum will take care of it easily. Then, you could login as root every day and fire up Mutt, and read the logwatch messages. Or, you could tell the mail server to give root’s mail to someone else, such as your own user account. All you have to do is login as root, and:
At the very bottom of the file, simply add a line which says:
The file itself explains the format; use a TAB between the colon and your username. Then close Gedit and run the command
newaliases. Then you only have to open a Terminal window every day and run Mutt yourself. Mutt is not user friendly, particularly for folks moving from Windows. I don’t like it either; I use something called Alpine. I’ll give you a hint that any email client you use, including the default Evolution on RHEL, can be set up to read mail directly from the internal mail server.
My habit is to use the commandline environment (AKA the console) for as much as possible — all my email accounts, a lot of Internet surfing, most of my editing, and so forth. If you get tired of Gedit, try
nano from the commandline for editing. It’s included in RHEL by default. Most of the keystrokes you learned in Windows tend to work the same, plus the window displays several important commands at the bottom.
Unless you are setting up a commercial grade operation, you really don’t have much chance to play with mail server administration. There was a time when most ISPs and such would tolerate a Linux user running their own mail server from home. That is, you could have your machine fetch mail from your accounts and pass it internally to your mail server. Then you could send mail from your server through the official servers where your accounts resided. Those days are gone. Very few mail servers out there will accept server connections from you, typically because your IP address is listed as non-server territory. They will only talk to your email client, not your server.
If you do have a genuine server connection to the Net, and you need to run a mail server operation, it’s hard for me to rewrite the instructions provided by Red Hat in their Deployment Guide. If you know what a mail server is supposed to do, it’s not that hard to plug in the values for the configuration files.
What I do want to explain is how RHEL lays out this operation. There are three programs you’ll be running in most contexts: Postfix, Dovecot and Procmail. Dovecot is the POP and IMAP server, what allows your users and clients to get their mail from your machine. Incoming mail is caught by Postfix, which passes it to Procmail for sorting. Procmail decides who gets what. You can also have Procmail filter for spam, by plugging in SpamAssassin. You’ll need to tell your mail system the various domains for which mail is accepted and handled, and where it goes. Postfix also handles your outgoing mail. As the system administrator, you would set up all the accounts for your users. Again, the RHEL Deployment Guide is not that hard to follow.
While the current crop of CentOS HOWTOs are somewhat dated, most of the details are still accurate. If you are serious about running a mail server, it’s a good place to start. You may want to consider using their Postfix and Dovecot with SASL for running the now standard secure login features for an organizational mail server.
There are some good tutorials from other sources, though some of them a little dated. One of the simplest, and missing instructions for Procmail, is at the CentOS website. Each of the three programs have their own website with more information than you can absorb: Postfix, Dovecot has a wiki, and Procmail has links at the bottom of their page to various tutorials.