If you’ve ever missed an important IRC discussion because you happened to be between home and the office at just the wrong time, or if you regularly log on from a number of different locations and don’t like juggling multiple IRC nicks, then you need an IRC proxy. The leading open source IRC proxy is Bip, a GPLv2 utility that is provided as a standard offering by most Linux distributions. This weekend, let’s set up Bip and stop missing important discussions!
What’s an IRC proxy, anyway? An IRC proxy is a small application that you can leave running on a machine with constant Internet access, such as a server. It connects to the IRC networks, and you connect to the proxy — either from the local machine or over a remote connection. To others on your IRC channel, you always appear available, and maintain the name nick. Meanwhile, you can disconnect from one location, then reconnect from another, and the proxy will replay all of the messages you missed in between. Let’s set it up!
The Plan
To start, let’s get Bip installed. It’s packaged for most Linux distros, just look for the “bip” package or search for IRC proxy. You can also download packages from the project’s Web site; the latest release is 0.8.7. Bip is command-line driven, which makes it a good fit for headless servers. The only dependency to speak of is OpenSSL, which is required in order to make secure remote connections.
Although Bip can be configured to run as a system-wide daemon, we will be setting it up in single-user mode, since we are primarily concerned with managing personal communications, not supporting an office-full of independent users. Most of the configuration is done through the bip.conf file, which you should place in a .bip directory inside your home folder. You can copy the sample bip.conf that comes with the Bip package; it will either be located at /etc/bip.conf or else in /usr/share/doc/bip/examples/, depending on your distribution.
Inside bip.conf, we will set up a Bip “user account” for ourselves, and the credentials we choose will be what we use in our IRC client app to connect to the Bip proxy. The IRC accounts that we would otherwise log in directly with are also detailed within bip.conf, with one “network” stanza per IRC server. Bip uses them to log in and authenticate to the IRC servers even when we happen to be disconnected.
Setting up bip.conf
The bip.conf file uses simple option = value; syntax, although a few values need to placed inside quotation marks — go by the example file for guidance. At the top of the file, for instance, you need to set ip = "127.0.0.1"; to tell Bip to accept connections only from local clients, while port = 7778; specifies the TCP port to listen over. You will definitely need to change the value of client_side_ssl to true, as this is what provides our security.
The basic options to consider are logging and backlog-replay behavior. By default, bip.conf specifies /var/log/bip/ as the logging directory — if you want to store IRC logs for long-term archiving, you should change this to another location, such as /home/yourusername/logs/irc/. The log_format string lets you specify a wildcard formula that Bip will use to keep separate logs for each IRC server and channel, optionally broken up into one-month archives. The default formula (which you must un-comment to use) is %n/%Y-%m/%c.%d.log — which creates a directory for each network (n), a subdirectory for each year-month combo (Y-m), and a separate file per channel (c) and day (d). You must uncomment the backlog option for Bip to replay missed traffic whenever you reconnect; backlog_lines specifies how many lines to replay (for no limit, choose 0).
Next, you’ll need to define the IRC networks Bip should know about. Each network section is a stanza enclosed in {curly braces}. It must contain at least a name such as “freenode” and a server definition, which consists of the hostname and port. Freenode, for example, would be server { host = "irc.freenode.net"; port = 6667;};. The “name” that you specify is purely for your convenience elsewhere in the file, but if you get the server settings wrong, you won’t be able to connect.
Finally, you’ll set up a Bip user account. The user stanza is also enclosed in curly braces, but it has several important sections. First, the name option is the Bip username you choose — it has nothing to do with your Linux username or IRC nicks; it just lets you connect to Bip. In the password field, you will need to open a command line in another window and run the helper program bipmkpw. This will ask you to create an account password (that you’ll need to remember), and will output a long hash string, such as 742437e63d25d20243e9c3217840ea2a91557504. Enter the hash into the password field in bip.conf.
Beneath this, but still inside of your user stanza, you can set up a default nick with default_nick and a default “real name” to accompany it with default_realname.
These are cross-server defaults. Below them (and still within user) you set up as many IRC connections as you need. Each connection stanza must reference one of the network names you defined above, plus list any channels you want to join automatically, and any network-specific connection options, such as a NickServ IDENTIFY command to authenticate yourself. A basic setup might look like:
connection {
name = "freenode"; #this is an internal-use only name
network = "freenode"; #this must be a reference to a previously-defined "network" stanza
user = "DoubleOhSeven";
on_connect_send = "PRIVMSG NickServ :IDENTIFY whateveryourNickspasswordis";
channel { name = "#emacs"; };
channel { name = "#vim"; };
};
Some of this seems repetitive (such as the connection and network names), but it is more useful in complex setups. You can check out a few additional options by reading man bip.conf, but this basic setup will maintain a single user’s connections.
Connecting to Bip
With bip.conf configured, you will now need to create an SSL certificate and key to use as your remote connection credentials. From a command prompt, run openssl req -new -x509 -days 365 -nodes -out bip.pem -keyout bip.pem and copy the resulting bip.pem file into your ~/.bip directory.
Now, launch the Bip application with bip &. Bip will connect to your configured IRC servers and join the channels specified in your bip.conf file. But you are still not connected to Bip, so all of your nicks are mindless automata, sitting silently and unresponsive in your favorite channels. Whether or not that strikes anyone else as out-of-character is beside the point — assuming you want to talk, you will need to configure your IRC client app to connect to Bip.
On a local machine, you can use Irssi, XChat, or any other IRC client that supports SSL to connect to Bip. Because your Bip service is not a public IRC server, you will need to add it to your client app’s list of known networks. You can use localhost as the server name and 7778 as the TCP port. For the server password, use the Bip account password you provided to bipmkpw. Do not use the hash value stored in bip.conf.
You will also need to make sure you specify using a secure SSL connection for the network preferences, and configure it to accept an “invalid” (or unverified) SSL certificate. That is normally a bad idea, but because the certificate we created is solely for our use with Bip, we are personally assured of its authenticity.
IRC clients these days tend to come pre-loaded with dozens of public IRC networks, and it would be a bad idea to erase the listing for Freenode or another public service, so name your Bip proxy’s connection something distinctive, like BipProxy. Now you can hit “connect,” and the Bip proxy will open up your IRC networks and channels, each tagged with the name you specified in bip.conf to help you keep them straight.
Connecting to Bip … Remotely
Connecting locally is great, but the real value of Bip is that you can disconnect and reconnect from a non-local machine, with your IRC buddies none the wiser. For this, all we need to do is have a properly configured IRC client on the remote machine, and SSH.
Start an SSH tunnel from the remote machine back to the server where Bip is running. You can do this with OpenSSH by running ssh -NfL 7778:localhost:7778 theaddressofyourBipserver.com. The L switch starts a port-forwarding tunnel between TCP port 7778 on localhost and port 7778 on the Bip server. The f and N switches run the resulting tunnel in the background and tell it not to expect a remote command, respectively.
All this means that TCP port 7778 on the Bip server is now tunneled directly to port 7778 on the remote machine, so you can use the same IRC client configuration: a Bip “network” setup in the list of IRC servers, again configured to use your Bip account password. That has the advantage of not requiring a radically different client configuration for your remote machines.
On the other hand, it does require that your Bip server be publicly accessible by SSH. Of course, that is a far cry better than having it be publicly accessible as an IRC relay, but it may still be a limitation for people running Bip on home ISP connections rather than hosted servers.
The other down side is that you need to set up the SSH tunnel before you launch the IRC client on the remote machine. Best practices here vary; perhaps the simplest thing to do might be to open the SSH tunnel at login time — obviously there are security implications to that if you are not careful, but I am not aware of any IRC clients that can do the tunneling step for you. Perhaps there are a few; some can run scripts and plug-ins. If you have advice on that subject, please tell your fellow readers below.
In the meantime, becoming an omnipresent IRC denizen is probably enough fundamental change for one weekend. You’ve got to save some time to read through all of those replayed messages, after all.
