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!
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development