E-mail as a System Console. Part I
Editors' Note: The following is a chapter from the book Multitool Linux, written by Michael Schwarz, Jeremy Anderson, Peter Curtis and Steven Murphy. Consult the book's web site for links, updates and errata.
Question: How can I get access to my home Linux system when I'm 1)at work behind a firewall that only allows me to send e-mail from my workstation or 2)away on a business trip and the hotel firewall only allows me to surf the Web?
Answer: Create an e-mail-based console application that let's you execute commands and return results via e-mail. If you're stuck with only web access, get a web e-mail account somewhere and use it to send commands over e-mail to your system at home. The e-mail console is a nice way to communicate with your system when normal communications (Telnet, ssh, FTP, what-have-you) are not available.
Have you ever been sitting around at work and wished you could execute a command on your home Linux system to find some information? I have and I bet you could find lots of reasons why you would want to do this as well. E-mail is simple, yet powerful. But can it be used as a console to your home Linux system? You bet! I use it all the time.
But why not just log in and execute commands in the traditional manner? Sure, I could do that, but that would be no fun. In addition, there are times when direct access to a system is not available. But if e-mail is available, then this e-mail console application will work for you. First, I'll tell you about how I arrived at developing the e-mail console, then I'll share how I did it.
If you're like me, at one time you probably connected to the Internet using a standard phone line and a local ISP. I like my ISP, but they limit the number of hours I can be on-line each month and charge me big bucks when I go over that limit. I won't switch ISP's because they are, without a doubt, the best in my area. Because of this restriction to my on-line adventures, I pick and choose the times when my Linux system will be on-line fetching e-mail, downloading files and so forth. The problem I have with this situation is I want access to my home system when I am at work. And when I'm at work, I often find myself needing to access my home system to get a file. With my monthly limit, I can't simply leave my computer continuously connected to the Internet during the day. What I need is a way to keep my home system off-line until I need it and then have it go on-line and stay that way until I tell it to disconnect.
Some time ago I decided to make it so my system would periodically connect to the Internet and download e-mail from my ISP using a nifty program called fetchmail. I wrote a few Perl scripts to automate and synchronize the connection requests from various applications, including SETI@HOME and fetchmail, which both need to connect to the Internet at various times. Plus, I needed to go on-line to surf around but not get disconnected when the fetchmail utility completed its work. Getting e-mail with fetchmail allows me to spend as little connection time as possible getting and responding to e-mail—why waste connection time typing replies?
The main goal of these scripts is to coordinate the connection and disconnection requests and keep my system on-line when needed. It then occurred to me that if I could somehow send an e-mail to my system (which picked up e-mail once an hour) and somehow have that e-mail parsed, so a command could be executed, I could tell my system to stay on-line or disconnect. Bingo! Now all I had to do was find that e-mail parsing, command-executing, dream utility. The solution was right under my keyboard.
On a piece of paper beneath my keyboard was a list of utilities I thought might be useful for dealing with my e-mail; procmail was one of them. Procmail, as it turns out, is an incredibly useful utility for performing searches on incoming e-mail and then performing some kind of action. Currently, I use procmail to parse my incoming e-mail every 15 minutes (I changed it from an hour down to 15 minutes so I wouldn't have to wait so long to access my system). It executes the command that tells my system to stay on-line after it is done fetching e-mail. Now, I can send e-mail to my home system with a special subject like “CONNECT REMOTE”, and my system will simply stay on-line after fetching and processing all the e-mail from my ISP. In my procmail configuration file, a recipe file, I searched for this string and then executed the Perl script I had written to make it so my system stayed on-line. I could also tell it to disconnect. Once I had this set up, it occurred to me that with a little more work, I could write a procmail recipe and Perl script that would execute any arbitrary command I gave it. This was the coolest thing I had ever heard of, and my "e;NT"e; friends would be so jealous!
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- New GeekGuide: Beyond Cron
- Designing Foils with XFLR5
- Users, Permissions and Multitenant Sites
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- diff -u: What's New in Kernel Development