Virtual Domains and qmail
The program qmail is a secure and reliable replacement for sendmail; it was written by Dan Bernstein at the University of Illinois at Chicago. I was attracted to it for several reasons, the most important being that it runs under Linux.
qmail is substantially more secure than sendmail. The system is partitioned into several modules, minimizing the amount of code which runs as root. The /var/spool/mail directory is gone; incoming mail for a user is stored in the user's home directory, eliminating a nagging security hole. qmail gives you control over which mail you accept. You can selectively allow other hosts to use your system as a relay, blocking out all others.
qmail supports mailing lists with automated subscriptions, and these lists can be configured and maintained entirely by the user. No intervention is required on the part of the system administrator to create a new list.
qmail's performance is stellar. Dan Bernstein cites Red Hat Software as an example. Red Hat was running sendmail 8.7 on a 48MB Pentium and found their daily load of 70,000 messages was beginning to overwhelm the system. They switched to qmail on a 16MB 486/66, and their mail hub is now running fine, even on the less powerful hardware.
The reason I began looking into qmail as an alternative to sendmail is the fact that qmail supported e-mail for virtual domains correctly long before sendmail did. Those of you running several virtual domains on a single Linux host can rejoice. With qmail, the e-mail names you select for your virtual domains come from per-virtual-domain name spaces, rather than a single host-wide name space. This means you can have e-mail names like email@example.com and firstname.lastname@example.org simultaneously.
The only problem we have had with qmail is the fact that its outgoing queue uses inode numbers in its database; this means the queue cannot be backed up on one machine and restored to another. When we have a disk failure, we must recreate an empty qmail queue directory rather than restoring from backup.
The fact that qmail is not sendmail implies some complications when installing add-on e-mail packages like majordomo. In general there are patched versions of these packages available for qmail.
The qmail sources are available at ftp://koobera.math.uic.edu/www/qmail.html and a lot of useful information is available at http://www.qmail.org/. Compilation and installation of qmail is straightforward. Those who balked at the sendmail.cf file will be pleasantly surprised at qmail's configuration. Everything is human readable and easy to understand. Some claim that sendmail.cf is human readable, but I would argue that point.
Once you have qmail configured and operational, you can start adding virtual domains. The rest of this article deals with virtual domains under qmail. All file and path names assume the default qmail installation.
Set up the new virtual domain normally. Many of you will have already done this to support the virtual domain with other services like Apache httpd. Make sure there is an MX record in DNS to point mail for the virtual domain to the host running qmail.
Create a master user ID and home directory for the new domain. The master user is just a user who will control all mail for your virtual domain. I generally create a user ID for each virtual domain which the administrators of that domain can use to upload the content for their web site. qmail can use the same user ID.
Add a line to /var/qmail/control/virtualdomains for the new domain, directing mail for that domain to the user created above. If the domain is abc.com and the user is abc, an appropriate line would be:
Add abc.com to /var/qmail/rcpthosts to tell qmail you're willing to accept mail addressed to abc.com. Ensure abc.com does not appear in /var/qmail/control/locals/.
Once mail is directed to a user, it is controlled through a series of .qmail-xxx files in that user's home directory. Create the file ~abc/.qmail-default, to indicate user abc is willing to accept all mail directed to the abc.com domain.
Restart qmail and e-mail for all users at abc.com, i.e., email@example.com, firstname.lastname@example.org, etc. will now be received by the local user abc. I suspect this is not precisely what you had in mind, so read on.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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