Seamlessly Extending IRC to Mobile Devices
Internet Relay Chat (IRC) is one of the older real-time communications methods still in active use on the Internet. Due to its popularity, flexibility and cross-platform nature, it still has a very vibrant user base today. Personally, I've been on IRC since the late 1990s, and it's been very useful and lots of fun—particularly the #linuxjournal room on Freenode—stop in sometime!
Drawbacks to IRC
As great as IRC can be, there's one thing about it that's always bothered me, and it's something that Jabber got right—the concept of a resource and priority. In IRC, when you log in as whatever user you are, you can't log in as that user again from another machine. Jabber allows multiple user logins, so long as the "resource" is different, and it'll route your messages to the client with the lowest priority. IRC doesn't even have that concept, so once you log in on your desktop, you have to log in as another user if you want to log in on your laptop, which results in lots of logins like "WildBill|Laptop" and such. This causes a problem if people want to private-message (PM) you, as they never know what login you're on.
For years, I've used a fairly common workaround to bypass this problem to a certain degree. If you use a text-based client like Irssi, and run that client on a machine that's on all the time, you can run the client within a terminal multiplexer, such as GNU Screen. That gives you the ability to run the client, detach from the terminal session, then log in via SSH on another machine and reattach to your session, where you can catch up on what you may have missed. By and large, this is an acceptable workaround...except when I forget to log in to that Screen session. I've been known to have a few days' worth of PMs piled up before I remember to log in and check. By that time, people who PM'd me probably forgot what they pinged me about.
The other major flaw with this scheme is that it doesn't work well with mobile devices like tablets and mobile phones. Yes, I could SSH from my iPhone to my Linux server and attach to that Screen session with Irssi running in it, but a terminal emulator on a 3.5" screen, where a good portion of the screen is taken up with an on-screen keyboard, is a recipe for a headache. There are excellent IRC clients for mobile phones, like Colloquy on the iPhone, Yaaic for Android and wIRC for WebOS, but if you run them while you have a Screen session going, you're back to the same problem mentioned above where you wind up with a "WildBill|Phone" login. There simply had to be a better way.
Is There a Better Way?
It turns out, after noodling around for a while one day, I did find a way. Irssi, the text-mode client I usually use via Screen and SSH, has a "proxy" (or "bouncer") mode where you can have it listen on a couple additional ports and then attach another IRC client to it. Enabling the proxy is relatively easy, and it can be done from within Irssi with only a few commands (assuming your Irssi is packaged and includes the proxy module). This also assumes you have Irssi already configured to work properly with whichever IRC networks you wish. Of course, substitute your own password for "mypassword", define whatever IRC networks you want to proxy with Irssi, and pick an arbitrary open port on which to have the proxy listen:
/LOAD proxy /SET irssiproxy_password mypassword /SET irssiproxy_ports linuxjournal=9000 /SAVE
Once you get the proxy module running successfully, connecting to it is as easy as pointing another IRC client at it. Just specify the fully qualified domain name of the host running your Irssi client in your second IRC client's configuration, and give it the password and ports you called out in the Irssi commands above. This client can be a "regular" desktop or laptop, or it can be a mobile device, such as an Android phone or an iPad running an IRC client.
Although this works just fine, it bothers me a little bit, as the password that's sent between the mobile device and your Irssi session that's running in Screen is sent in the clear. I'd much prefer that to be SSL-encrypted, so no one can intercept that password. Unfortunately, the Irssi proxy module doesn't support SSL, but there's a way around that through the use of the stunnel utility.
Stunnel is a generic encryption wrapper that's designed to add SSL encryption to any non-encrypted service. It's not hard to wrap the Irssi proxy service with stunnel. First, to prevent anyone on the outside from accessing the proxy without SSL, I bound the ports on the Irssi proxy to the loopback interface using the following Irssi command:
/SET irssiproxy_bind 127.0.0.1 /SAVE
Next, use your distribution's method for installing stunnel. On Ubuntu
10.04, a simple
sudo apt-get install stunnel4 took care of that. I
had to create a self-signed SSL certificate (see Resources
for a how-to on this), and I put that cert in /etc/stunnel. Next, I had
to create an /etc/stunnel/stunnel.conf that referred to the certificate
I created and specified the Irssi proxy in the stunnel.conf file. An
example follows below (adjust the file paths, "accept" IP address
and port as necessary):
; stunnel.conf code snippet ; Certificate/key is needed in server mode and optional in client mode cert = /etc/stunnel/cert.pem key = /etc/stunnel/key.pem [linuxjournal] accept=184.108.40.206:9000 connect=127.0.0.1:9000
So, what the previous code snippet does is specify the cert/key file for the self-signed SSL cert, then binds the SSL side of stunnel to the external IP address 220.127.116.11 on port 9000, and it'll hand off packets to my Irssi proxy running in the clear on 127.0.0.1 (localhost) on port 9000. The last adjustment to this setup would be to go to the mobile device and specify that the IRC connection should be SSL, and now I have a secure proxy I can attach to with any client of my choice. Now I can log in to IRC from my regular Irssi client, but then when I'm on my phone, I can use the friendlier interface that Colloquy provides, all without having different nicknames on IRC.
Being "Pinged" and Getting Alerted
I still have a problem though. I still forget to log in to IRC and check my private messages—and some friends stack up many "pings" before they finally give up in frustration. I got to thinking and realized that since I'm on a mobile phone, it might be possible to send an e-mail to the SMS gateway my mobile provider runs when I get a PM. That'd give me a reminder to log in to IRC in the event that I forget. After searching the Internet for a bit, I discovered some other fellow had much the same idea. Michael Lustfield explains it on his blog in far more detail than I can put in this article (there's a link in the Resources section), but I'll summarize his technique here. He's got two Irssi scripts he uses: screen-away.pl monitors if there's an active connection to the Irssi proxy, and awayproxy.pl sends any highlights off to a designated e-mail address if there isn't an active client connected to the Irssi proxy.
Figure 1. Getting an SMS on WebOS
"But Bill...e-mail isn't an SMS!" You may think that, but just
about every mobile carrier can accept SMS messages for delivery to
a mobile phone via e-mail. In my case, I use AT&T, so any e-mail sent
to <myphonenumber>@txt.att.net will arrive as a text message on my
phone. So, all I have to do is drop Michael's scripts in my Irssi scripts
folder, adjust awayproxy.pl so that the
firstname.lastname@example.org, and then activate both scripts from
within Irssi by doing a
/script load awayproxy.pl
screen-away.pl. Now, any mention of my name in any of the channels I
sit in will cause an SMS to be fired off to my phone, and I can log in
from my phone or tablet and jump into the conversation.
Figure 2. Jumping into the Conversation—Using wIRC on WebOS
Bill Childers is the Virtual Editor for Linux Journal. No one really knows what that means.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
1 hour 26 min ago
5 hours 2 min ago
- Reply to comment | Linux Journal
5 hours 35 min ago
- All the articles you talked
7 hours 58 min ago
- All the articles you talked
8 hours 1 min ago
- All the articles you talked
8 hours 3 min ago
12 hours 27 min ago
- Keeping track of IP address
14 hours 18 min ago
- Roll your own dynamic dns
19 hours 32 min ago
- Please correct the URL for Salt Stack's web site
22 hours 43 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?