I've been working on a small program called EINAL (Email Is Not Always Loved.) The program logs into Gmail-based accounts and matches strings with senders or subject lines and deletes them. Why? Because while Gmail has filters that will send emails to the trash, there's no built-in mechanisms for actually removing the email.
For some people that's fine. They archive the mail or stick it into the trash and ignore it. Then there are people like me who often has to check on something in the trash because someone had a question, and I don't use the Gmail interface where everything is found via a query and email storage is more or less modeled after the method an eight year old uses to organize his toys in the middle of the living room. Not to mention that I hate having extra storage taken on my various mail clients and my phone's email client when I literally have status emails several times an hour popping into my mailbox.
EINAL is pretty self-contained; it creates a subdirectory where the login credentials, subject lines and email sender lines are stored. Then there's another subdirectory under it where EINAL stores a logfile of activity and log of deleted emails, should I need to refer to a subject line that no longer exists in my mailbox. Because EINAL is written in Go, I don't need to worry about external dependencies.
The Goal
I created EINAL with two modes; one for single runs (good for testing and tuning, configuring the accounts to log into, or modifying the search strings) and one for "background use" where the application waits for you to log into it via SSH and enter the decryption phrase. At that point it will begin checking every X number of minutes for messages to delete from the mail accounts.
There are a few ways I pictured the "background" operation to work.
1) Run it as a daemon on a laptop; my personal system, my work computer, or, because EINAL was written in Go and was portable, perhaps my development Raspberry Pi computer at the office.
2) Run it as a user-application at login; I was thinking of trying to get it to run on one of my Macs as a startup application.
3) Run it as an application in a VM.
4) Run it as a detached-from-terminal process on the dev/testing Pi.
Each had potential drawbacks.
1) If you create a daemon the "correct way", you know that it's a PITA to have the application properly reply to signals and behave in the weird environment processes find themselves in once they move from the world of a terminal to the realm of detached processes. This also limits portability to some degree. There are special libraries dedicated to assisting with daemonizing processes as well as special wrappers and whole posts dedicated to writing proper startup/shutdown scripts depending on the distro you're targeting.
2) I tried going through references on how to launch the application at startup on my Mac. EINAL needed at least the -background flag to run in background mode; running it as a startup item would just launch the application. I'd have to instead run a startup script, and then I'd have to tinker with that until the proper environment variables were set and working.
3) Running it as a VM is a nice sandbox method of isolating the environment in which EINAL runs and is semi-portable (depending on how large the virtual disk ended up.) Unfortunately unless I ran this on one of our company server farms, it would be rather resource intensive to run a whole operating system just to run my application. Also any restarts on the workstation would cause the VM to go down until someone intervened.
4) Running it on the Pi as a background process or in a detached Screen session was actually an appealing idea. Of course I'd become obsessed with finding a way to script the startup of the application and some way to notify me when it restarts so I'd know I have to log in to EINAL to give the encryption phrase.
So far the fourth option sounds best. EINAL isn't a resource hog. it shouldn't take too much tinkering to get it running on the RPi.
On Second Thought
Then it occurred to me that I might want to investigate something new that was becoming popular at the office; using Docker as a sandbox and deployment tool for EINAL. I should learn more about it; it was a way to (at least partially) automate deployment, and learning Docker should prove valuable as it's becoming popular in up-and-coming technologies.
And beside, it might be interesting to have Docker running on a Raspberry Pi.
In the next part, I discuss setting up Docker on my Raspberry Pi!
In the next part, I discuss setting up Docker on my Raspberry Pi!
No comments:
Post a Comment