Tips from The Answer Guy
Is there any way (or any program out there) which will not only get my e-mail from a POP3 server off of one account, but distribute it to multiple users on my system by either the from: or subject: lines?
Perhaps popclient could get the mail and save to temp. Then a program could go through the saved mail and say, “Hmmm, this mail is from email@example.com and it goes to root—then the next message is from firstname.lastname@example.org and it goes to Dave.” Is there a program that will do this? —Moe Green, email@example.com
It is possible to write procmail scripts that can take this sort of action for you. Although I don't recommend this approach, I'll tell you how to do it.
The current version of popclient is called fetchmail, because it supports IMAP and some other mail store and forward protocols. The fetchmail default is to fetch the mail from your POP or IMAP server and feed it to the smtpd (sendmail) on your local host. This means that any special processing that would be done by the aliases or .forward files (especially any processing through procmail scripts) will be done automatically.
It is possible to override that feature and feed the messages through a pipe or into a file. It is also possible, using procmail or any scripting language, to parse and dispatch the file. Using anything other than procmail would require that you know a lot about RFC822, the standard for Internet mail headers, and about e-mail in general.
I wrote an article on procmail that appears in February's Linux Gazette, Issue 14. The gist of it is also available on my own mail server, and can be obtained by sending mail to firstname.lastname@example.org with a subject of procmail or mailbot.
The reason I don't recommend using procmail in this way is that it violates the intentions and design of Internet e-mail. A better solution is to find a provider of UUCP (Unix-to-Unix CoPy) services or at least SMTP/MX (Simple Mail Transfer Protocol) services. UUCP is the right way to provide e-mail to disconnected (dial-up) hosts and networks. It was designed and implemented over 25 years ago, and all of the mail systems on the Internet know how to gateway to UUCP sites.
As for SMTP/MX services for disconnected hosts/networks, there are various ways of hacking sendmail and DNS (Domain Name Service) configurations that have been developed in the last few years with a variety of shell scripts and custom programs to support them. All of these methods provide essentially the same services as mail via UUCP over TCP but do not conform to any standard, which means that whatever you learn and configure with one ISP probably won't work with the next one. —Jim
Recently a cracker got into my Linux system on the Internet. He didn't do a lot of damage, but I guess he did turn off system logging, since I couldn't see what he'd done. Now I can't get it working again. Here's what I've done so far:
I've made sure that the syslogd program is running using ps.
I've read the syslogd.conf file to make sure it's logging everything, and where it's going to.
I've checked permissions on the log file.
I did a kill -HUP on the syslogd process, and it writes restart to the log.
logger does nothing when I run it (no log entry, no error).
All my C programs that wrote to syslog don't anymore.
Anyone have any good ideas what to do from here? —Jayjay@shadow.ashpool.com
I do, but they are rather too involved for me to type up tonight. However, I highly recommend that you reinstall the OS and all binaries from scratch whenever you think root has been compromised on your system. I realize this is a time-consuming proposition, but it is the only way to truly be sure.
I also recommend the program tripwire that can be found at ftp.cs.perdue.edu in the COAST archive, and its mirrors.
Please feel free to write me at email@example.com if you continue to have system security problems.
Sorry to take so long to respond. I've been literally swamped all month. —Jim
I found that the cracker had replaced my syslogd with a packet sniffer. I think he had copied the syslogd code and replaced parts of it with his sniffer. It seemed to have some functionality but not a lot...
I also found a SUID version of bash in my /tmp directory. My thought is this is the way he originally got root access. —Jay
Not too surprising. He was probably using a rootkit; however, he obviously didn't do a very good job of covering his tracks. You should consider all passwords for all of the systems on the local net to be compromised. Force password changes across the board and consider installing ssh or stelnet. Both are secure, encrypted replacements to rlogin/rsh and telnet respectively.
He probably got in through the “Leshka” sendmail bug that allows any shell user to create a root-owned SUID shell in /tmp/ on any system that has an SUID root copy of sendmail (version ~8.6.x to 8.7.x ?). The bug involves sendmail's handling of ARGV and it's subsequent SIGHUP (signal to disconnect) handling. Everyone using earlier versions of sendmail should upgrade to 8.8.3 or later (see http://www.sendmail.org/ for details).
How important are this system and the other systems on the same LAN segment to your business? I'd seriously consider hiring a qualified consultant for a full day risk assessment and audit. Unfortunately, you'll probably pay at least $125/hr for anyone that's worth talking to, and many of the “security consultants” out there are snake oil salesmen, so beware. —Jim
This article was first published in Issue 14 of LinuxGazette.com, an on-line e-zine formerly published by Linux Journal.
Jim Dennis is the proprietor of Starshine Technical Services. His professional experience includes work in technical support, quality assurance and information services (MIS) for software companies like Quarterdeck, Symantec/Peter Norton Group and McAfee Associates—as well as positions with smaller VARs. He's been using Linux since version 0.99p10 and is an active participant on an ever-changing list of mailing lists and newsgroups. He's just started collaborating on the 2nd Edition for a book on Unix systems administration. Jim is an avid science fiction fan—and recently got married at the World Science Fiction Convention in Anaheim
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!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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