Before we go any further, I should make clear what we're about to build. I've chosen the SMTP gateway scenario because it's such a common role for sendmail and because it's so dependent on good security (in most organizations, publicly accessible mail servers face scarier if not more numerous threats than internal mail servers do).
An SMTP gateway typically needs meticulous attention to privilege levels, file permissions and in general, only as much enabled functionality as is needed to route mail. On such a host, sendmail should run as an unprivileged user where possible; it should run chroot-ed (in a subset of /) at least when writing files, and it should be configured to relay mail only for your organization, not for spammers.
It takes very little tweaking to harden sendmail on Red Hat 7 for SMTP gateway use and only a little more on SuSE and other distributions.
I can state with absolute certainty that your Linux distribution of choice includes one or more packages for sendmail. Whether it's presently installed on your system and whether it's an appropriate version for you to use, however, is another matter.
If you use an RPM-based distribution (Red Hat, Mandrake, SuSE, etc.), you can see whether you've got sendmail installed and which version by issuing the command rpm -qv sendmail. Note that Red Hat and its derivatives split sendmail into three packages: sendmail, sendmail-cf and sendmail-doc. SuSE uses a single package, sendmail.
So, what version should you run? As of this writing, the latest version of sendmail is 8.12.2. Red Hat 7 and SuSE 7, however, still support variants of sendmail version 8.11. As far as I can tell, there's nothing wrong with sticking with your distribution's supported sendmail package if it's version 8.11.0 or higher. There were no major security problems in the 8.10 or 8.11 releases; 8.11, in fact, was a “features” release: rather than being released to patch security holes, it was released because the sendmail team had added support for TLS encryption and for the SMTP AUTH extension to SMTP.
If you've got the time and/or inclination, though, it's never a bad idea to compile and install the latest stable version. For sanity's sake, I'll assume for the remainder of this article that you're using sendmail 8.10.0 or higher (unless otherwise noted).
Debian GNU/Linux v2.2 (Potato) still supports sendmail v.8.9.3. Although this is a stable and apparently secure release, it's now two major versions old (if one considers the second numeral to represent a major version, which I do because the first numeral has been eight for half a decade). In addition, 8.9.3 doesn't support TLS or SMTP AUTH.
If you want TLS or SMTP AUTH, or are uncomfortable running an older version, you always can uninstall the package, download the latest source code tarball from www.sendmail.org and compile and install sendmail from source. The source code tarball is well documented and compiles easily under Linux, assuming you've got a working gcc installation.
Once you've installed sendmail, either in the form of a binary package from your distribution or from a source code tarball you've compiled yourself, you've still got a couple of tasks left before you can configure and run the sendmail executable as a dæmon.
If you're a SuSE user, become root if you aren't already. Next, open /etc/rc.config with your text editor of choice and set the variable SMTP to “yes”. This is necessary for sendmail's startup script in /etc/init.d to run at boot time.
In addition, you need to edit the file /etc/rc.config.d/sendmail.rc.config so that the variable SENDMAIL_TYPE is set to “no”. Doing so essentially will disable SuSEconfig's use of /etc/rc.config.d/sendmail.rc.config, which in other circumstances can be set up to generate a simple sendmail configuration automatically. We're going to set up an SMTP gateway/relay, which is a bit beyond the scope of sendmail.rc.config. But if your host is to act only as a simple SMTP server for its own local users, it will probably suffice to edit this file (having first set its SENDMAIL_TYPE variable to “yes”); if so, you'll find sendmail.rc.config's full documentation in /etc/mail/README.
After editing rc.config and sendmail.rc.config, run SuSEconfig. This will propagate the changes you just made to rc.config and sendmail.rc.config. To start the dæmon you can enter the command /etc/init.d/sendmail start, but I recommend you wait until sendmail is fully configured before you do so.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Managing Linux Using Puppet
- Returning Values from Bash Functions
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide