HOWTO: Persistence and IRC
Posted
Modified
Comments
0
IRC?
We at Sysadministrivia can be a little old-school about some things. One of those things is our chat – we use and like IRC. (We’ve been considering moving to XMPP with an IRC transport to our current channel on Freenode, but we’ll see.)
For reference throughout this article, know that the IRC network we use is Freenode (irc.freenode.org), and our channel is #sysadministrivia – but it requires authing to Nickserv to join!
Unlike more recent centralized and proprietary chat systems (and XMPP), IRC doesn’t have an in-protocol method for message persistence – i.e. if your local client disconnects, you can catch up on messages that were said in your absence (“scrollback”, as we commonly refer to it). After all, IRC is 26 years old (at the time of writing this article) so cut it a little slack (no pun intended).
Thankfully there are several options to help address this shortcoming.
Please note that unless you have:
- A machine in your LAN that is always on…
- that you can securely and remotely connect to
- and you have a very friendly ISP
- and can forward ports to it, …
Your best bet is to get a VPS. You don’t need one with high specs. We at Sysadministrivia use and love Linode VPSes, but any (ideally Linux, as that’s going to give you the most flexibility) VPS should do. (Worth noting that the smallest Linode plan, which would be perfectly capable of any of the below solutions, is only 5USD/mo. If even that’s too steep, Vultr has a plan that is 2.50USD/mo.)
Irssi + SSH + (Tmux|Screen)
This is what all three hosts of Sysadministrivia use (and probably the majority of our IRC channel regulars do as well). Optionally, you can use byobu (alternate link), a tmux/screen wrapper. Despite being an Ubuntu project (I can hear Jthan raging from here), it actually is pretty good and lets you even use Screen bindings for Tmux or vice versa. I use Tmux as the backend for byobu, I believe Jthan uses Screen as his byobu backend, and Paden just uses plain screen.
Note that irssi isn’t strictly necessary, but the below is tailored to it. Any CLI/Curses/nCurses client will work fine with this solution; the important meaty bits are the SSH and Tmux/Screen (and Byobu, if you decide to use it) parts. You can even use finch, the non-X version of pidgin with it! (And yes, it works with bitchX just fine.)
Components necessary:
- irssi
- an ssh daemon running (duh – you should already have this set up)
- either screen or tmux.
- (optional) byobu
All of this software should be available in your distro’s repositories if you’re using some form of Linux.
If you use byobu, you can simply do byobu-enable, exit, and reconnect via SSH and it’ll be set up to spawn a Tmux/Screen session automatically when you log in.
What I personally do is I like to configure irssi to be able to connect to networks and join channels automatically (which is out of scope for this, but their website has great documentation – specifically, you can automate authing to nickserv with SASL on Freenode, which is the IRC network we use). I then set up irssi to start automatically when I first login:
~/.tmux.conf
set -g default-shell /bin/bash
set -g default-command /bin/bash
select-window -t irssi:0/etc/systemd/system/irssi-kill@.service
This systemd unit is necessary to quit irssi cleanly on system shutdown (otherwise it’ll just close irssi, which means the IRC networks need to wait for you to timeout to release your nick, … just trust me on this.) The below assumes you’re using a system with systemd, as most distros are these days.
Drop this in place, do a systemctl daemon-reload, and systemctl enable irssi-kill@YOURUSERNAME
[Unit]
Description=Kill irssi sessions for user %I
[Service]
User=%I
Group=%I
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/bin/tmux send -t irssi:0 /quit ENTER
[Install]
WantedBy=multi-user.targetAnd that’s it! You should be good to go. Obviously tweak where necessary/possible for Screen implementations instead.
Pros/Cons
Pros
- Irssi is very flexible
- It also allows you to implement bitlbee so you can connect to other chat protocols within the same client.
- Or you can use finch as hinted above and have this built into the client, either/or.
- It lets you easily use other features of screen/tmux.
Cons
- Some people like the clicky-clicky shiny. This ain’t it.
- You’ll have to set up something like irssi-fnotify or another plugin if you want inotify/etc.-type notifications on a graphical client machine/DE.
Irssi Proxy
Not many know that irssi has a built-in proxy. That link has all the information you need, so I won’t go into too much detail here.
Pros/Cons
Pros
- You can use irssi on a local machine and still keep a persistent session open on a remote server.
- You don’t need to connect to your remote end with SSH to use it.
Cons
- You’ll very most likely still want to set up the irssi + SSH + screen/tmux method above, as you still presumably have to detach from the remote SSH session.
- Only supports irssi as the connecting client to the proxy (at least it did the last I checked).
ZNC
Ah, now we’re talking! ZNC is what’s known as an “IRC bouncer” – it lets ANY IRC client connect to a persistent IRC “client daemon”.
The above link is pretty straightforward, so I won’t delve too deeply into it.
Pros/Cons
Pros
- Entirely client agnostic; it doesn’t care what IRC client you use on the “true client”/workstation/whatever-you-want-to-call-it end. Everything from irssi (see above) to HexChat and everything in-between etc. will work.
Cons
- A lot of VPS providers really do NOT like you running an IRC bouncer on their platform, and it is more likely to violate their respective AUP.
- Requires root access (which you DO/SHOULD get with a VPS, but I digress…) to enable the daemon as it’s a service.
Quassel Core
Quassel is a project that aims to combine ZNC (see above)’s role – an IRC bouncer – and a graphical client together. The Quassel docs and the Arch Linux wiki article on it both do a fantastic job (especially when used together) in getting you set up with it, so I won’t cover it here.
Pros/Cons
Pros
- Boy howdy, the shiny! The clicky! GUI all the things!
Cons
- Like irssi proxy, it requires you to use the associated client (to my recollection) – it’s not a true IRC bouncer.
XMPP Transport
XMPP supports something called transports/gateways. The configuration and support for this is going to wildly differ depending on your XMPP server software, so I won’t get into it here. (We personally recommend ejabberd, which does support IRC transports via the mod_irc module. The configuration can be tricky but well worth it.)
Pros/Cons
Pros
- It’s XMPP! XMPP’s awesome!
- You’ll easily be able to use S2S if we switch over to XMPP for our chat, so the transition will be very painless for you.
Cons
- Are you seriously going to set up XMPP just so you can talk in our IRC?
Comments
There are currently no comments on this article.
Comment...