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=18.104.22.168: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 22.214.171.124 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.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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