Hanging out in the amount of channels I do, I see a lot of activity in my statusbar for all of my joined channels. This can be overwhelming for some, but I don’t mind it. What I do mind, however, is when I check in on a specific channel, and see pages and pages of scrollback that is nothing more than people joining and leaving the channel. I’ve tried blatantly ignoring JOINS, PARTS and QUITS, as they’re called, but I always disable it, because I usually want to be kept abreast of when someone leaves a channel that I’m having a conversation with. I don’t want to look silly continuing to chat to someone, long after they’ve left. So, I need a way to keep on top of when people are joining and leaving the channel, but not have that information in the channel itself. Thankfully, Irssi meets this need.

The concept is simple. A JOIN, PART or QUIT is what is referred to as a “level”. There are a number of different levels that Irssi supports, all of which can be found with “/help levels” in Irssi. With Irssi, it is possible to ignore, or even redirect, levels. In my case, I want to redirect these three levels to another window, if possible. So, digging through the settings in Irssi, I found “window_check_level_first”. By default, this setting is “OFF”, which means that Irssi has a global setting for levels, and how they’re handled. Enabling this setting, means to follow the levels that have been assigned to their respective channels. However, if you turn this on first, without doing some initial setup before hand, you’ll notice everything going to your status window by default, including chat. This isn’t what we want, so let’s get setup.

The first thing we need to do is set our levels for all of our currently open windows, as well as any future windows that we open. We can accomplish this with two commands in Irssi:

/foreach window /window level ALL -JOINS -PARTS -QUITS
/set window_default ALL -JOINS -PARTS -QUITS

Now, the next thing to do is to create a new hidden window that will be the new home for all your JOINS, PARTS and QUITS. So, from Irssi:

/window new HIDDEN

Navigate to that window, wherever it is placed, and give it a name. For me, I called it “junk”. Of course, this isn’t necessary, just optional, but I prefer that each of my windows have a name:

/window name junk

It will have picked up the -JOINS -PARTS -QUITS from our default setting we just applied, so we’ll need to reverse that. Easiest way is to just apply the converse of what you did earlier:

/window level -ALL JOINS PARTS QUITS

Sweet. Our window is finished. Now, we can turn on the setting that will tell Irssi to look for each individual window level setting:

/set window_check_level_first ON

Wait a bit, and you should see all the JOINS, PARTS and QUITS going to your new hidden window, rather than each respective channel. You’ll also notice that it doesn’t print the channel where these are originating. I don’t know of an easy way to set that without a script, so if you know of such a script that exists, or want to write one yourself, sharing that would be appreciated. In the meantime, this is better than nothing.

Don’t forget to save:

/save

Also, you may not want to make your “junk” window hidden, but rather make it sticky, and split Irssi, putting the junk window on the top. I’ve done this with my highlight window, so it would make sense here. In that case, just:

/window stick on
/window show (number|name)

You can then size the window as needed if you decide you split your Irssi.

And, there you have it. Now, when people are joining and quitting, rather than filling your scrollback where precious chat exists, it’s all being forwarded to a window of your choice. If eventually, you like this setup, and you find that you’re not checking your junk window for joins and quits, then you may be able to get away with just ignoring JOINS, PARTS and QUITS altogether Irssi-wide. Which means, if for any reason you want to reverse this setup, it’s rather trivial:

/set window_check_level_first OFF
/foreach window /window level ALL
/set window_default ALL
/window close
/save

And that would back you out of this configuration, and get you back to default.

I should mention that I’ve heard that WeeChat has a feature that only people you’ve recently chatted with will show when they quit, or there is a setting for setting this. I personally think WeeChat is a solid client. However, in this case, I don’t want to see any quits, even with those I’m chatting with, in that buffer. However, I would like to see it in another buffer, and Irssi makes this painless. So, while I’m sure WeeChat can also meet similar needs, Irssi meets my needs best.

As with my other Irssi tutorials, I hope this one was helpful. I find that I personally benefit from my own writing, and that’s the major reason why I blog. I have searched for doing solving problems in the past, only to stumble upon my own blog post, outlining the very issue I’m faced with again. So, if it won’t benefit you, at least it will benefit myself.

Before beginning any installation, you should be very familiar with your hardware, so you know what sort of drivers you’ll need for the installation, and if there will be any compatibility issues. Attempting to put Debian on this machine in the past has failed, due to the network driver not shipping with the Lenny kernel. If you have this netbook, the NIC is an Attansic Technology Atheros AR8132/L1c gigabit ethernet adapter. The driver is open source, however, the hardware is so new, that at the time I had purchased the Mini, the driver hadn’t been included in the mainline kernel. The wireless is a Broadcom BCM4132, which means the firmware is not open source, and as a result, not included with the Debian installer. So, at the time, there was no way to get this netbook online with Debian. However, with the release of the 2.6.29 kernel, the Aetheros driver needed was included, and the development snapshot of the installer now ships that kernel, so we’re good to go with a network installation, and getting the computer online.

All the other hardware that I’ve tested, I have tested before with different hardware other than the Mini, and worked out of the box. So, the installation should be rather straightforward, and booting in the new system should be on par with a working system.

So, in order to perform a Debian GNU/Linux installation via USB, you need only a few things. First, you must grab a boot.img.gz file from the development snapshot of the installer for your hardware. Because the HP Mini is x86 32-bit, I grabbed mine here. Now, you also need a CD image file (ISO format) which will contain the necessary software and installation procedures for the install. I prefer to do network installs, so I grabbed a netinst ISO here.

The boot.img.gz file will contain a bootable syslinux kernel and initial ramdisk, which means it will have the drivers necessary for your hardware. Of course, I got mine from a development snapshot, so I could get the Atheros NIC driver from the latest kernel, but if you have older hardware, maybe the stable version of the boot.img.gz would work better for you. You just need to get it from any hd-media directory appropriate for your architecture. The ISO on the other hand contains the base software for installing to disk, the partitioner and other parts of the installer necessary for performing the installation. The boot.img.gz just gets you started.

Now that you have both files, you’ll need a USB thumb drive that is at least 256MB in size, which shouldn’t be a problem these days. Insert the USB drive into a computer with a working Linux operating system, and determine the appropriate device assigned to your newly inserted drive. You can get this information a number of ways. Probably the best way, is to run the following command before you insert the USB drive:

# tail -f -n 0 /var/log/messages

Then, insert the drive. You’ll see output from the kernel as it discovers the hardware and assigns a device to the drive. For me, my output was this:

Feb 21 08:22:28 hermes kernel: [46103.644130] usb 1-7: new high speed USB device using ehci_hcd and address 7
Feb 21 08:22:28 hermes kernel: [46103.789569] usb 1-7: New USB device found, idVendor=13fe, idProduct=1e00
Feb 21 08:22:28 hermes kernel: [46103.789586] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 21 08:22:28 hermes kernel: [46103.789599] usb 1-7: Product: USB DISK 2.0
Feb 21 08:22:28 hermes kernel: [46103.789609] usb 1-7: Manufacturer:
Feb 21 08:22:28 hermes kernel: [46103.789618] usb 1-7: SerialNumber: 077904015F40
Feb 21 08:22:28 hermes kernel: [46103.789974] usb 1-7: configuration #1 chosen from 1 choice
Feb 21 08:22:28 hermes kernel: [46103.790939] scsi5 : SCSI emulation for USB Mass Storage devices
Feb 21 08:22:33 hermes kernel: [46108.838495] scsi 5:0:0:0: Direct-Access              USB DISK 2.0     PMAP PQ: 0 ANSI: 0 CCS
Feb 21 08:22:33 hermes kernel: [46109.101380] sd 5:0:0:0: [sdb] 4030464 512-byte logical blocks: (2.06 GB/1.92 GiB)
Feb 21 08:22:33 hermes kernel: [46109.101984] sd 5:0:0:0: [sdb] Write Protect is off
Feb 21 08:22:33 hermes kernel: [46109.107382]  sdb:
Feb 21 08:22:33 hermes kernel: [46109.174851] sd 5:0:0:0: [sdb] Attached SCSI removable disk

So, in my case, the newly inserted drive is /dev/sdb. So, armed with this information, I can now prepare the USB drive. This next step should be handled with caution. If you type in, whether intentionally or accidentally the wrong device, disasterous consequences may abound. As a friend once told me: “read twice, type once”. Think what you’re doing before you do it. So, at this point, I just need to send the contents of the boot.img.gz file to the new disk. I would not recommend doing it to a partition, but instead doing it to the whole drive. If you inserted your thumb drive, and you noticed in the output that you have a /dev/sdb and /dev/sdb1, then this means you have a partition table outlining a single partition on the drive /dev/sdb. Ignore the partition, work with the drive itself.

Make sure your USB drive is NOT mounted, then type in the following (this next step will remove any existing partitions and data on the drive):

# umount /dev/sdb*
# zcat boot.img.gz > /dev/sdb

This should only take a couple of seconds to finish. At this point, you’ll have a FAT16 formatted USB drive with a syslinux install on the drive. You will now need to mount the drive and copy the ISO image to the mount point.

# mount /dev/sdb /mnt
# cp debian-504-i386-netinst.iso /mnt
# sync
# umount /dev/sdb

At this point, you have a fully prepared USB thumb drive with all the necessary bits in place to perform a USB installation on your netbook, or other hardware. When you boot from the USB stick, you’ll have the familiar Debian installer interface- automated installation, beginner and expert modes and a rescue environment. Because of this, I would recommend keeping the USB stick close at hand, should you need to troubleshoot your installation any time soon.

When you initialize the installation, the installer will look for an ISO file that contains the Debian software. It will start with /dev/sda, and work it’s way device-by-device and partition-by-partition in order, until it finds the ISO file. Because my drive is also recognized as /dev/sdb on my netbook, it only take a couple seconds. After it has found the ISO image, you’re ready to install, just like you would if you had booted off a CD.

That’s it! Rather straightforward, I think. You only need four times really to complete the job:

• You computer
• A USB disk
• A boot.img.gz file
• An ISO containing the Debian software

Good luck on your USB installs!

Adding your Facebook account to Bitlbee is rather painless, as it is with any other account. The only catch, is you have to have a Facebook username set before you can continue. Once that is set, in Bitlbee, from your “&btilbee” status window, you can add the account:

account add jabber <username>@chat.facebook.com <password>
save
account on

That’s it! You should be up and running with a new XMPP connection to the Facebook chat. However, rather quickly, you’ll notice that the usernames in your “blist” roster are their user identification number on Facebook, rather than their name. Something like “u123456789″. Who is that you wonder? Well, in your “&bitlbee” window, you could run:

info u123456789

Then, using that information, you could rename them one-by-one as they login. However, this is a pain. Fortunately, if you’re running Bitlbee with Irssi, then there is an Irssi Perl script for renaming these automatically for you, as they login. You can find that script here. Save it as “bitlbee_rename.pl” in your “~/.irssi/scripts directory, create a symlink in the autorun directory, load it, and you’re set. Here’s what you would do behind the command line:

wget -O ~/.irssi/scripts/bitlbee_rename.pl http://browsingtheinternet.com/temp/bitlbee_rename.txt
ln -s ~/.irssi/scripts/bitlbee_rename.pl ~/.irssi/scripts/autorun/bitlbee_rename.pl

Now in Irssi, load it:

/RUN bitlbee_rename.pl

Now, each of your Facebook buddies will have their user ID number renamed to “FirstnameLastname” format. The script only works for Facebook chat, so no worries about it mucking up other XMPP connections, and it only renames buddies that haven’t already been renamed. It also saves it to your Bitlbee config (which is /var/lib/bitlbee/username.xml) every time it renames a buddy.

So, there you go. Bitlbee, XMPP and now Facebook, married together. What a beautiful relationship.

When I used to teach system administrators for a living, I gave them the mantra that if you have a tool that can modify a config file, use the tool. The tool has most likely been tested for bugs, and will generate syntactically correct configs. Humans are error-prone, so editing a config by hand means setting yourself up for error and pain. For Irssi, the developers have put in rather extensive commands that can modify everything in the config directly, and there’s even an exhaustive documentation support structure behind those commands. So, there should be no reason to edit the Irssi config by hand.

To show this, in irssi, go to the status window, and type “/help”:

/help
05:29 Irssi commands:
05:29 accept     disconnect  lastlog  op        script     unquery
05:29 action     echo        layout   oper      scrollback unsilence
05:29 admin      eval        links    otr       server     upgrade
05:29 alias      exec        list     part      servlist   uping
05:29 away       flushbuffer load     ping      set        uptime
05:29 ban        foreach     log      query     sethost    userhost
05:29 beep       format      lusers   quit      silence    ver
05:29 bind       hash        map      quote     squery     version
05:29 cat        help        me       rawlog    squit      voice
05:29 cd         hilight     mircdcc  recode    stats      wait
05:29 channel    ignore      mode     reconnect statusbar  wall
05:29 clear      info        motd     redraw    time       wallops
05:29 completion invite      msg      rehash    toggle     who
05:29 connect    ircnet      names    reload    topic      whois
05:29 ctcp       ison        nctcp    resize    trace      whowas
05:29 cycle      join        netsplit restart   ts         window
05:29 dcc        kick        network  rmreconns unalias
05:29 dehilight  kickban     nick     rmrejoins unban
05:29 deop       kill        note     rping     unignore
05:29 devoice    knock       notice   save      unload
05:29 die        knockout    notify   sconnect  unnotify   

So, long story short, don’t edit the config. Use the commands, and learn the help system. With that out of the way, let’s begin.

I’ve encountered many who are using Irssi that don’t understand how a few key commands relate with each other and how to tie them in. So, I would like to cover those commands here, namely: /channel, /network, /server and /connect. Hopefully, by the end of this post, not only will you be comfortable enough with the commands I’ve taught you about, but you’ll be comfortable enough to use the built-in documentation should you be stuck.

/network
The first command to learn is /network, because all the rest of the commands take advantage of it. So, we’ll start there. /network is used for defining some client-specific settings you want to apply when connecting to a server. These settings can include username, real name, nickname, usermodes and other goodies. Running “/help network” can show you everything it supports:

05:32 NETWORK ADD [-nick <nick>] [-user <user>] [-realname <name>] [-host <host>] [-autosendcmd <cmd>] [-querychans <count>] [-whois <count>] [-msgs <count>] [-kicks <count>] [-modes <count>] [-cmdspeed <ms>] [-cmdmax <count>] <name>
05:32 NETWORK REMOVE <network>
05:32
05:32      -kicks: Maximum number of nicks in one /KICK command
05:32      -msgs: Maximum number of nicks in one /MSG command
05:32      -modes: Maximum number of mode changes in one /MODE command
05:32      -whois: Maximum number of nicks in one /WHOIS command
05:32      -cmdspeed: Same as /SET cmd_queue_speed, see section 3.1
05:32      -cmdmax: Same as /SET cmds_max_at_once, see section 3.1
05:32      -nick, -user, -realname: Specify what nick/user/name to use
05:32      -host: Specify what host name to use, if you have multiple
05:32      -usermode: Specify what usermode to use on this network
05:32      -autosendcmd: Command to send after connecting to a server
05:32
05:32 With -autosendcmd argument you can automatically run any commands after connecting to network. This is useful for automatically identifying yourself to NickServ, for example
05:32
05:32 Shows and changes the settings of defined IRC networks.
05:32
05:32 See also: CONNECT
05:32
05:32 Irssi commands:
05:32 network add network list network remove 

So, let’s go ahead an define some networks. I personally connect to several networks simultaneously, all of which have different usermodes, and some which I need to provide authentication to when connecting. So, let’s say I wish to define client-specific connections to Freenode, OFTC and bitlbee. Let’s look at what to add. Oh, by the way, every command and option provided by Irssi can be tab-completed. Worth knowing to save some typing.

/network add -user 88 -realname eightyeight -nick eightyeight -usermode +iw freenode
/network add -user 88 -realname eightyeight -nick eightyeight -usermode +w oftc
/network add -user aaron -realname "Aaron Toponce" -nick aaron -autosendcmd "say identify password" bitlbee

As you can see, each network line is different. I’m using the same username, real name and nick for “freenode” and “oftc”, but different ones for “bitlbee”. I’ve specified different user modes with “freenode” and “oftc” where I haven’t provided any with “bitlbee”. Further, with “bitlbee”, I’m sending an identify command to the server when I connect. As you can probably imagine, this gives me great flexibility on how I want my client to interact with different servers.

Running “/network list” should show you the three servers you just added:

/network list
05:48 Networks:
05:48 freenode: nick: eightyeight, username: 88, realname: eightyeight, usermode: +iw
05:48 bitlbee: nick: aaron, username: 88, realname: Aaron Toponce, autosendcmd: say identify password
05:48 oftc: nick: eightyeight, username: 88, realname: eightyeight, usermode: +w

If you’ve just installed Irssi, you will likely find many networks already defined, including OFTC. If this is the case, and you want to make some adjustments to the OFTC definition, go ahead and provide those in the “/network add” command, and those options will be appended, provided the network name is the same. If you wish to remove any of the networks, then as you learned in the help doc, “/network remove name” is the syntax for that.

It’s important to note that at this stage of the game, any of the commands you enter in Irssi are only used for the current running session. If you wish to keep the settings persistent, then you will need to save it to disk (your config). You can do this with the “/save” command. I would recommend saving often when manipulating Irssi. Further, if for some reason you make a mistake in the command you’re typing, and you wish to revert back to the previous “/save” command, then you can use “/reload” for this purpsoe. “/reload” will read the config, and load the settings it finds there, ignoring any previous settings you’ve defined without saving.

/channel
Now with our networks defined for our client settings, let’s define some channels to visit when we connect to these networks. So, in the status window, what does “/help channel” show?

05:56 CHANNEL LIST
05:56 CHANNEL ADD [-auto | -noauto] [-bots <masks>] [-botcmd <command>] <channel> <network> [<password>]
05:56 CHANNEL REMOVE <channel> <network>
05:56
05:56 Irssi can automatically join to specified channels in specified IRC networks. It can also automatically send the password when manually joining to channel without specifying the password.
05:56
05:56 /CHANNEL ADD [-auto | -noauto] [-bots <masks>] [-botcmd <command>]
05:56              <channel> <network> [<password>]
05:56
05:56 With -bots and -botcmd arguments you can automatically send commands to someone in channel. This is useful for automatically getting ops for channels, for example
05:56
05:56 /CHANNEL ADD -auto -bots "*!bot@bothost.org bot*!*@host2.org"
05:56              -botcmd "msg $0 op mypass" #channel ircnet
05:56
05:56 You can also use the -botcmd without -bots argument. The command is then sent whenever you join the channel.
05:56
05:56 If you want to remove some settings from existing channel record, for example bots, just give the -bots "" parameters to it. Password can be removed by setting it to - (or actually, "" works too).
05:56
05:56 You can remove the channels with /CHANNEL REMOVE <channel> <network>
05:56
05:56 /CHANNEL LIST displays list of channels with settings.
05:56
05:56 /CHANNEL without any arguments displays list of channels you have joined. You can also use /CHANNEL to join to channels just as with /JOIN, like /CHANNEL #a.
05:56
05:56 See also: TS, JOIN
05:56
05:56 Irssi commands:
05:56 channel add channel list channel remove 

As you can clearly see with “/channel”, we can define what channels to join, and if any, what bot commands to send to the channel when we join. Each channel we join will be based on the network that we’ve previously defined. So, I could join #ubuntu whenever I connect to the Freenode network and #debian whenever I connect to the OFTC network. As with “/network”, on a fresh install of Irssi, there may already be a couple channels defined. Feel free to keep them in play when using Irssi, or remove them with “/channel remove” as per the syntax in the help doc.

So, let’s define some channels:

/channel add -auto #ubuntu freenode
/channel add -auto #freenode freenode
/channel add -auto #debian oftc
/channel add -auto #bitlbee oftc

Pretty straight forward, right? I’ve added four channels, two on the “freenode” network and two on the “oftc” network. Because Bitlbee doesn’t handle “channels” necessarily the same way IRC servers do, I haven’t defined any channels to join when I connect to Bitlbee. Notice I’m passing the “-auto” switch, so when I join that network, I’ll automatically join those channels. This is entirely optional, and “-noauto” is default if “-auto” isn’t passed.

As with “/network”, you can append settings to each channel listing as needed, as long as the channel name and network name are the same. If you wish to remove some settings, then you’ll need to “/channel remove” and “/channel add” as appropriate. Running “/channel list” should show our progress thus far:

/channel list
06:05 Channel         Network    Password   Settings
06:05 #ubuntu         freenode              autojoin
06:05 #freenode       freenode              autojoin
06:05 #debian         oftc                  autojoin
06:05 #bitlbee        oftc                  autojoin

Again, you should run “/save” when you’ve defined your channels, so next time you start Irssi, your settings won’t be lost.

One last related note about your channels. For me, I get very used to the location, or layout, of my channels. When I lose my running Irssi connection, for whatever reason, nothing is more frustrating than the channels being in a different order than previous. Fortunately, I’m not the only one that this annoys, so the developers have provided “/layout save” as a way to keep my sanity. “/layout save” will save the location order of your channel windows, so should you join a channel again, it will go to the same location as it was in previously. However, as with every other command in Irssi, this will only save it to your currently running session in RAM. If you wish to keep it persistent, you must issue “/save” for the next time you start Irssi.

/server
At this point, we’re ready to connect. We have all the details out of the way, and we could easily just connect to Freenode or OFTC. However, we may want to pass some server-side options to the networks, such as connecting via SSL. So, before covering “/connect”, let’s get “/server” out of the way, as it’s the last command in this post that does any saving to disk, then we’ll play with “/connect”. As is verbatim in this post, let us pull up the help doc:

06:24 SERVER [-4 | -6] [-ssl] [-ssl_cert <cert>] [-ssl_pkey <pkey>] [-ssl_verify] [-ssl_cafile <cafile>] [-ssl_capath <capath>] [-noproxy] [-network <network>] [-host <hostname>] [-rawlog <file>] [+]<address>|<chatnet> [<port> [<password>
             [<nick>]]]
06:24 SERVER PURGE [<target>]
06:24 SERVER REMOVE <address> [<port>]
06:24 SERVER ADD [-4 | -6] [-ssl] [-ssl_cert <cert>] [-ssl_pkey <pkey>] [-ssl_verify] [-ssl_cafile <cafile>] [-ssl_capath <capath>] [-auto | -noauto] [-network <network>] [-host <hostname>] [-cmdspeed <ms>] [-cmdmax <count>] [-port
                 <port>] <address> [<port> [<password>]]
06:24 SERVER LIST
06:24
06:24      -4, -6: specify explicitly whether to use IPv4 or IPv6 address
06:24      -ssl: use SSL when connecting
06:24      -ssl_cert: The SSL client certificate file (implies -ssl)
06:24      -ssl_pkey: The SSL client private key (if not included in the certificate file)
06:24      -ssl_verify: Verify servers SSL certificate
06:24      -ssl_cafile: File with list of CA certificates (implies -ssl_verify)
06:24      -ssl_capath: Directory with CA certificates (implies -ssl_verify)
06:24      -noproxy: Ignore the global proxy configuration for this server
06:24      -auto: Automatically connect to server at startup
06:24      -noauto: Don't connect to server at startup (default)
06:24      -network: Specify what IRC network this server belongs to
06:24      -ircnet: Same as -network. Deprecated. Do not use
06:24      -host: Specify what host name to use, if you have multiple
06:24      -!: don't autojoin channels
06:24      -cmdspeed: Same as /SET cmd_queue_speed, see section 3.1
06:24      -cmdmax: Same as /SET cmds_max_at_once, see section 3.1
06:24      -port: Use this only to edit the port number of an existing server,
06:24             for new servers use the <port> argument
06:24
06:24 /SERVER disconnects the server in active window and connects to the new one. It will take the same arguments as /CONNECT. If you prefix the address with the + character, Irssi won't disconnect the active server, and it will create a
      new window where the server is connected (ie. /window new hide; /connect address)
06:24
06:24 /SERVER without any arguments displays the list of connected
06:24         servers.
06:24
06:24 /SERVER REMOVE <address> [<port>]
06:24
06:24 /SERVER LIST
06:24
06:24 /SERVER PURGE [<target>]
06:24
06:24 Clears the server send queue. Useful if, for example, you accidentally paste lots of text to a channel.
06:24
06:24 See also: CONNECT, DISCONNECT, RECONNECT, RMRECONNS
06:24
06:24 Irssi commands:
06:24 server add server connect server list server purge server remove 

As should be obvious, this help doc is rather verbose. There are a lot of options that you can send server-side, such as using IPV4 or IPV6, connecting via SSL, changing the connecting port, and a myriad of other options. Let’s pick on just a few, and I’ll let you examine the rest.

Just the other day, I posted on how to connect to Freenode using SSL, and yesterday I covered connecting to OFTC in a similar manner. Let’s take those “/server” strings, along with one for Bitlbee to define how I wish to connect to these servers. As with the previous commands, the syntax is “/server add”, as the help doc mentions:

/server add -auto -ssl -ssl_verify -ssl_capath /etc/ssl/certs -network freenode irc.freenode.net 7000
/server add -auto -ssl -ssl_cert ~/.irssi/certs/nick.pem -ssl_verify -ssl_cafile /etc/ssl/certs/spi-cacert-2008.pem -network oftc irc.oftc.net 6697
/server add -auto -network bitlbee localhost

As you can see, I’m using SSL for the Freenode and OFTC connections, but not for bitlbee. Further, I’m specifying “-ssl_cert” with OFTC to present my self-signed certificate to NickServ, which I’m not doing to the others and I’m using a specific CA certificate to verify the OFTC SSL cert, whereas with Freenode, I’m specifying a whole CA path, and letting it choose the appropriate CA certificate for verification. Lastly, with all three connections, I’m automatically connecting to the networks, so when I launch up Irssi, it begins connecting right away. Because there are channels with “-auto” added to them, when the server connection is successful, I’ll join those channels right away, and my session will be ready to go without any interaction from me.

If I wish to see the listing of servers I just added “/server list”, as per the documentation, will show me that list. Again, on a fresh install, there may be more servers than what we have added here, and you can keep them in play, or remove them as needed. If OFTC is already defined in the server list, then you can make changes to the listing as long as the port number, network name, and server url are the same. If there are settings you wish to remove, then you’ll need to “/server remove” and re-add as appropriate.

So, what does our listing show us:

/server list
06:50 Server               Port  Network    Settings
06:50 irc.freenode.net     7000  freenode   autoconnect, ssl, ssl_verify, ssl_capath: /etc/ssl/certs
06:50 irc.oftc.net         6697  oftc       autoconnect, ssl, ssl_cert: ~/.irssi/certs/nick.pem, ssl_verify, ssl_cafile: /etc/ssl/certs/spi-cacert-2008.pem
06:50 localhost            6667  bitlbee    autoconnect

As you can quickly see, where we specified ports for Freenode and OFTC, we didn’t for Bitlbee, so the default IRC port 6667 was added. Of course, don’t forget to “/save”, so you don’t lose your work up to this point.

A cautious word about “/server”. “/server” is used for defining server connections, not for connecting to servers themselves. However, it can connect you to a server should you say something of the effect to “/server irc.mozilla.org”. If you did this, it will disconnect you from your current connections, and ONLY connect to you irc.mozilla.org. This is an unfortunate side-effect that many first time Irssi users discover. The proper method for connecting to irc.mozilla.org is to use “/connect irc.mozilla.org”, as we’ll discuss below.

/connect
Our last command that I plan on covering in this post. With our networks defined and our servers and channels configured, we could easily at this point connect to Freenode, and all of our settings that we’ve set at this point would be applied, which means it will save us SERIOUS amounts of typing in the future, provided you don’t keep setting up Irssi over and over. Let’s first look at the help doc, as we did with the other commands, then we’ll see how simple our life is from here on out.

/help connect
06:58 CONNECT [-4 | -6] [-ssl] [-ssl_cert <cert>] [-ssl_pkey <pkey>] [-ssl_verify] [-ssl_cafile <cafile>] [-ssl_capath <capath>] [-noproxy] [-network <network>] [-host <hostname>] [-rawlog <file>] <address>|<chatnet> [<port> [<password>
              [<nick>]]]
06:58
06:58      -4, -6: specify explicitly whether to use IPv4 or IPv6 address
06:58      -ssl: use SSL when connecting
06:58      -ssl_cert: The SSL client certificate file (implies -ssl)
06:58      -ssl_pkey: The SSL client private key (if not included in the certificate file)
06:58      -ssl_verify: Verify servers SSL certificate
06:58      -ssl_cafile: File with list of CA certificates (implies -ssl_verify)
06:58      -ssl_capath: Directory with CA certificates (implies -ssl_verify)
06:58      -network: the network this connection belongs to
06:58      -ircnet: Same as -network. Deprecated. Do not use.
06:58      -host: the host
06:58      -!: don't autojoin channels
06:58      -rawlog: immediately open rawlog after connected
06:58
06:58 This command makes irssi to connect to specified server. Current connections are kept and a new one is created.
06:58
06:58 See also: SERVER, DISCONNECT, RMRECONNS, SCONNECT

Obviously, “/connect” is verbose, but not as verbose as “/server”. Further, the first thing to note about “/connect” is there is nothing to save. This command just takes the settings you’ve already defined for your networks, and applies them in to the connection string. However, should you not have a defined network or server to connect to, such as maybe connecting to irc.mozilla.org, you can use many of the settings in “/server” here, such as IPV4, IPV6, SSL and so on. So, say I’m wishing to test an IPV6 connection to irc.mozilla.org, I could issue something like the following:

/connect -6 irc.mozilla.org

That’s it! If it succeeds, then maybe I can add it to my server list with “/server add”, as discussed above and “/save” to the config. Maybe I want to test SSL over IPV6 on that network on a specific port. I could do this. Further, because I’ve already defined my networks, I can say something like:

/connect freenode

In this case, I’ll apply all the network settings AND server settings for the “freenode” connection. This keeps me from typing it over and over every time I wish to connect. Further, the network names themselves can be tab completed! Oh, how this makes life much more enjoyable!

At the end of the help document, you’ll notice a couple of additional commands. Namely “/disconnect” and “/rmreconns”. If you’re finished with a network, and wish to disconnect, then “/disconnect” would be what you want. For example, maybe you’re satisfied with your testing of IPV6 over SSL on irc.mozilla.org. Then, from your status window, you will need to tell Irssi that this is the connection you wish to disconnect. To do this, “^x” (control-x) will switch you servers until you reach the right one. Then, when you’ve switched to the right server you could issue:

/disconnect

Further, maybe a “/connect” isn’t working. Maybe you’re trying to reach a host that is currently down, it’s timing out, or the server on a different port than what you specified. As a result, Irssi won’t be able to connect to your preferred server, but it will keep trying. Eventually, maybe the host will become responsive, and a connection can be made. Maybe not. Regardless, Irssi will keep trying your “/connect” one way or the other. This might be undesirable, so running “/rmreconns” will remove any reconnections that Irssi is attempting to make. As with every other Irssi command, “/disconnect” and “/rmreconns” have a help doc.

Conclusion
So, that’s it. I hope this was helpful. If it was just noise, or much of it was confusing, I hope you walk away from this tutorial with at least two things:

1. /help
2. /save

If you can get those two commands deeply cemented in your brain, then you’ll be okay navigating Irssi and learning its ins and outs. Further, while there might be nothing technically wrong with editing the config by hand, Irssi provides powerful, powerful tools that can do it for you keeping the errors out, and the documentation for those tools, while not perfect, is vast and very complete. But, hopefully, you see now the relationship between “/network”, “/server”, “/connect” and “/channel”, and how you can tap into that power to make your Irssi experience more pleasurable.

First, the reason I do NOT endorse.

Hitler and Nazism
The letter “H” is the eighth letter of the alphabet in many languages, including German. So, substituting the number 8 directly to a letter of the alphabet results in H. 88 substituted results in “HH”. Apparently, “HH” is short for “Heil Hitler!” in German. So, people who use the number 88 are associating themselves with the Nazi regime and the cause of Hitler, showing their support. I am NOT one of these people! I do not support Hitler, Nazism, antisemitism or anything related to WWII, the Third Reich, etc. I am not a skinhead, I don’t own a Broken Cross, I don’t persecute anyone for their religious beliefs, I don’t hang out in gangs, and I don’t believe the Caucasian “race” is superior to any other. I have nothing to do with this movement, old or new, and people who know me personally, know this is the case. I value life, religious tolerance and racial and social equality. As far as I’m concerned, Adolf Hitler was one of the most, if not the most, immoral and unethical people in the 20th century.

So, if you take one thing out of this, take this: I don’t support Hitler, his regime, his values, nor his sadistic, screwed up way of viewing politics.

Now, the main reason why I chose this nickname.

The Piano
For the uninitiated, there are eightyeight keys on a standard piano, and guess what? I play the piano. I formally started at 6 years old, and had formal and informal training on and off from that point to today. During my early teen years, I found a passion for competing in local, regional and statewide competitions, and participated in them frequently. Not only this, but I played the piano for choir as an accompanist, I played the piano for school musicals, I played the piano in band and orchestra when appropriate, and I play the organ now for my church. I have taught lessons, and still play quite frequently, despite my very busy schedule. When I reached about 16 years old, kids in school started calling me “88″ or “88 keys”. I think this was the result of the Warren Beatty film Dick Tracy that debuted about the same time, and kids who had seen it thought it was an appropriate nickname for me.

Now, not all pianos or keyboards for that matter have eightyeight keys. The Bosendorfer Imperial Grand, a piano that I have yet to play on, has a full 13 octaves, from low C to the high C- an astonishing 97 keys. Organs, while not pianos, have many manuals that can total far more or far less that eightyeight keys. However, it’s generally understood that a standard piano has eightyeight keys, starting from the low A and reaching the high C.

There are other reasons why I like this number.

Asian culture
The word eight implies wealth in Mandarin Chinese, and as a result, symbolizes good luck and fortune. This is quite the drastic difference from neo-nazi culture. In fact, the Asian culture have deep roots in the luck and wealth that the number 8 brings. Many prices in markets, stores and other places will be littered with eights. A price of fruit, for example, might be $1.88 or 88 cents. Further, the Beijing Olympics started on August 8, 2008 (8/8/08) at 8:00pm. Coincidence? I can say as well that 8 has been a lucky number for me, although not necessarily 88.

Aside from playing the piano, I’m also a Mathematician and Computer Scientist. There are some interesting qualities of the number 88 in mathematics. Some of which are listed below:

Palindromic
I have always enjoyed palindromes. I don’t know why, but when I first learned about them in elementary school, I would sit at my desk, and think up as many palindromes as I could. “NOON”, “MOM”, “DAD”, and “TENET” were some of the words I came up with at that age. Then, of course, I would do the same with palindromic numbers as well. 88 was especially cool, because I could write in in the fancy “S” where you drew two rows of three lines, and connected them with diagonals. Remember that? Of course you do. You thought it was cool then too.

Primitive Semiperfect
A semiperfect number in mathematics is where all or some of the factors of the number sum up to the number itself. For example, the factors of the number 6 are 1, 2, 3 and 6. Adding those factors results in 6. Another semiperfect number is 20, where its factors are 1, 2, 4, 5, 10 and 20. 10+5+4+1=20. 88 is semiperfect. Its factors are 1, 2, 4, 8, 11, 22, 44 and 88. 44+22+11+8+2+1=88.

So, what is a primitive semiperfect number? This is a number where it is not divisible by any other smaller semiperfect number. Knowing the factors of 88, you can see this is the case, as the smaller semiperfect numbers in sequential order are: 6, 12, 18, 20, 24, 28, 30, 36, 40, 42, 48, 54, 56, 60, 66, 72, 78, 80 and 84, none of which are a factor of 88. As a result, 88 is primitive semiperfect.

Refactorable
A refactorable number is an integer where the count of its factors is divisible by that integer. For example, 9 is refactorable. It’s factors are 1,3 and 9. There are three factors, and three itself is a factor of 9. Another refactorable number is 40. Its factors are 1, 2, 4, 5, 8, 10, 20 and 40. There are 8 factors of 40, including 40 itself, and 8 is a factor of 40. There are also 8 factors of 88, and guess what? 8 is a factor of 88. 88 is refactorable.

Untouchable
An untouchable number is a positive number that cannot be written as the sum of all the divisors of any other number excluding its greatest factor. For example, the number 4 is not untouchable, because the factors of 9 are 1 and 3 (excluding 9 itself), which sum to 4. 5 however is untouchable, as there is no number where all of the factors add strictly to 5. 88 falls in this category.

Hexadecagonal
Many numbers can be thought of shapes using dots or pebbles arranged in the shape of a polygon. For example, the number 6 is triangular, as six pebbles can be arranged to form an equilateral triangle. 10 is the next triangular number. 9 on the other hand is rectangular, arranging the pebbles in a square. What is hexadecagon? It’s a 16-sided polygon with 16 vertices. So, this means 88 pebbles can be arranged into an equilateral hexadecagon.

Conclusion
I hope you can see that there are many interesting facts about the number 88, including Nazism. 88 has cultural significance in many cultures, of which I only mention two. It has many interesting mathematical properties, and even has astronomical significance. For example, it takes eightyeight days for Mercury to complete its orbit around the Sun. So, now that you’ve read this post, I hope you walk away a bit more informed, a bit more knowledgeable, and less judgmental. 88 is a great number, and I can recognize it for its unique and interesting qualities. Can you?

Generating an OpenSSL Certificate
OFTC runs a forked version of hyperion-ircd that they call oftc-hybrid. It’s a patched version of hyperion that Freenode was running on their servers before the switch to ircd-seven. It supports IPV6, SSL, and CertFP with NickServ, that I’ll cover later in this post.

Before connecting to OFTC, we want to generate an OpenSSL certificate. This certificate will be used for authenticating to NickServ, and really isn’t related to setting up an SSL connection to OFTC. However, when you connect, you will be presenting OFTC with the generated certificate, and at that point, you will be able to add it to NickServ, because it’s been presented. If you already have your own personal certificate you want to use, then you can skip this step, and move on to connecting with SSL.

I’m going to assume you have OpenSSL installed. If you’re running any modern Unix-like operating system, such as GNU/Linux or one of the BSDs, chances are very high that it’s been installed by default. If not, install it, and continue with the rest of the post.

In this step, we’re going to generate our own self-signed personal OpenSSL certificate. So, fire up a terminal, type in the command below, and follow the on-screen instructions. The values you put here do not matter to OFTC in the least, so fill them in any way you wish. In my case, I’ll fill in the data for my personal certificate, but you fill in the values as you see fit. Replace “nick.key” and “nick.crt” with your IRC nick that you use for this connection.

cd ~/.irssi
mkdir certs
cd certs
openssl req -nodes -newkey rsa:2048 -keyout nick.key -x509 -days 365 -out nick.crt
Generating a 2048 bit RSA private key
writing new private key to 'nick.key'
-----
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Texas]:Utah
Locality Name (eg, city) [San Antonio]:Ogden
Organization Name (eg, company) [Stealth3]:eightyeight
Organizational Unit Name (eg, section) [ISP]:OFTC
Common Name (eg, YOUR name) []:Aaron Toponce
Email Address []:aaron.toponce@gmail.com

Now, if you look, you’ll have two newly generated files: “nick.key”, which is your private key and “nick.crt” which is your public self-signed certificate. Because “nick.key” is your private key, you want to guard it appropriately. Its permissions should be modified to only be readable (and maybe even writable) by you, and you alone. Also, because we have both the private and public key set, let’s go ahead and combine the files into one PEM file that we’ll present to NickServ when connecting:

cat nick.crt nick.key > nick.pem
chmod 0400 nick.key nick.pem

Connecting with SSL
At this point, we are ready to connect to OFTC, and present our certificate to the server. So, fire up Irssi if you haven’t already:

irssi -!

Now that we’re in Irssi, we want to setup our SSL connections to OFTC. You should have ~/.irssi/certs/nick.pem available to send.

We will need to retrieve the CA certificate for verifying the server certificate. I personally like to put all my CA certificates in my certificates store, and this is where I deviate a little from the tutorial on the OFTC site. OFTC has their certificate signed by Software in the Public Interest, so we’ll need their CA certificate. Fortunately, Debian, Ubuntu, and many other GNU/Linux operating systems provide this certificate for us, so we just need to identify the location of the certificate, and plug that into Irssi. If you don’t have that certificate, refer to the tutorial on the OFTC site for obtaining it and installing it on your system.

So, with Irssi waiting for our command, let’s tell it out to connect to OFTC:

/network add oftc
/server add -auto -ssl -ssl_cert ~/.irssi/certs/nick.pem -ssl_verify -ssl_cafile /etc/ssl/certs/spi-cacert-2008.pem -network oftc irc.oftc.net 6697
/save
/connect oftc

When we successfully connect, we should see that OFTC has accepted our self-signed certificate in the MOTD, and it should also show that we are connected securely to the network with SSL:

16:20 [oftc] Irssi: Looking up irc.oftc.net
16:20 [oftc] Irssi: Connecting to irc.oftc.net [64.62.190.36] port 6697
16:20 [oftc] Irssi: Connection to irc.oftc.net established
16:20 [oftc] [charm.oftc.net]: *** Looking up your hostname...
16:20 [oftc] [charm.oftc.net]: *** Checking Ident
16:20 [oftc] [charm.oftc.net]: *** Found your hostname
16:20 [oftc] [charm.oftc.net]: *** No Ident response
16:20 [oftc] [charm.oftc.net]: *** Connected securely via TLSv1 AES256-SHA-256
16:20 [oftc] [charm.oftc.net]: *** Your client certificate fingerprint is 4A5463CE416649F72818B22945681D28250C1ACA
16:20 [oftc] >>> Welcome to the OFTC Internet Relay Chat Network eightyeight

Sweet! We’re connected securely, and OFTC accepted my client certificate by printing the fingerprint for me. If the fingerprint is not displayed, then OFTC has not accepted my certificate, and I need to review the steps outlined above, or on their site.

Authenticating to NickServ with SSL
From here on out, our connection is secured, and we can enjoy the safety that is encrypted packets. So, at this point, we need to register our nick with NickServ, if we haven’t already. It should be pointed out that Services has a complete help document provided. Messaging “help” to any of the Services bots will give you a break down of the available commands and their syntax. I would highly recommend becoming familiar with how to use the provided documentation.

/msg NickServ help
04:22 [notice(NickServ!services@services.oftc.net)] *** NickServ Help ***
04:22 [notice(NickServ!services@services.oftc.net)] ACCESS: Maintains the nickname ACCESS list.
04:22 [notice(NickServ!services@services.oftc.net)] CERT: Maintains the nickname client certificate list.
04:22 [notice(NickServ!services@services.oftc.net)] DROP: Releases your nickname for use.
04:22 [notice(NickServ!services@services.oftc.net)] ENSLAVE: Enslave a nickname to this master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] HELP: Shows this help.
04:22 [notice(NickServ!services@services.oftc.net)] IDENTIFY: Identify your nickname.
04:22 [notice(NickServ!services@services.oftc.net)] INFO: Get information on a nickname.
04:22 [notice(NickServ!services@services.oftc.net)] LINK: Link this nickname to a master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] LIST: Shows a list of nicknames matching a specified pattern.
04:22 [notice(NickServ!services@services.oftc.net)] RECLAIM: Release your nickname for you to use.
04:22 [notice(NickServ!services@services.oftc.net)] REGAIN: Release your nickname for you to use.
04:22 [notice(NickServ!services@services.oftc.net)] REGISTER: Registers a nickname for your usage.
04:22 [notice(NickServ!services@services.oftc.net)] SENDPASS: Send a password reset request.
04:22 [notice(NickServ!services@services.oftc.net)] SET: Set nickname properties.
04:22 [notice(NickServ!services@services.oftc.net)] STATUS: Shows the identified status of a nickname
04:22 [notice(NickServ!services@services.oftc.net)] UNLINK: Unlink this nickname from a master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] *** End of NickServ Help ***

In this case, we’re interested in registering and then identifying. The syntax for registering is providing your password and email as arguments. Providing the correct email is key, so should you lose your password and you can no longer authenticate with SSL, you can have NickServ email you your password. So, I would recommend putting in a valid email here, and not some throw away string:

/msg nickserv register password username@example.com
/msg nickserv identify password

At this point, our nick is registered and we are identified to NickServ. If the nick you’re wishing to register is already registered, then you’ll either need to pick a different nick, or join #oftc on the network, and see if staff can assign that nick to you. At any event, you must be identified with a valid nick before you can proceed with the next steps.

Now that we are identified to NickServ, we need to add our hostmask to the access list. This is beneficial, so we won’t be asked to identify when we connect, which is what we want. So, we need to find our hostmask. This is simple enough by running a /WHOIS on yourself, and identifying your host string. So, it might be something like this:

/WHOIS eightyeight
04:29 [oftc]      nick  | eightyeight
04:29 [oftc]      host  | ~88@c-12-130-240-233.hsd1.mn.comcast.net
04:29 [oftc]     gecos  | eightyeight
04:29 [oftc]    server  | charm.oftc.net [Freemont, CA, USA]
04:29 [oftc]      info  | user has identified to services
04:29 [oftc]  hostname  | 12.130.240.233
04:29 [oftc]      info  | is connected via SSL (secure link)
04:29 [oftc]      idle  | 0d 0h 1m 48s [signon: Sat Jan 30 16:20:12 2010]

In this case, my host is “~88@c-12-130-240-233.hsd1.mn.comcast.net”. This is what I want to provide to NickServ:

/msg nickserv access add *@c-12-130-240-233.hsd1.mn.comcast.net

Good. Now we’re ready to add our self-signed certificate. Remember, when you connected, in the beginning of the MOTD, your certificate fingerprint was displayed. You will want to copy this output and paste it here. You can also use the “openssl” command to get the fingerprint of your cert, you will just need to remove the colons out of the string when providing it to NickServ. In my case, my fingerprint was 4A5463CE416649F72818B22945681D28250C1ACA, so I’m going to add that. Change the string for your fingerprint:

/msg nickserv cert add 4A5463CE416649F72818B22945681D28250C1ACA

That’s it! At this point, if you were to connect again (you must /disconnect and then /connect. /reconnect doesn’t apply the SSL settings, apparently (BUG?)), you will find that you will automatically identify to NickServ with your cert, and without a password. As you can imagine, this is highly secure. If you are not taking advantage of SSL, then your password can be sniffed on the wire, and your account could be compromised. In this case, we’re neglecting the password, and using public key cryptography instead to authenticate. I don’t know at this point if a MITM attack would be successful. So, bonus.

To see that it has succeeded, when you connect you should see the following at the end of the MOTD:

05:14 [oftc2] >>> You have set user mode +i
05:14 [oftc2] >>> You have set user mode +R
05:14 [oftc2] [notice(NickServ!services@services.oftc.net)] You are connected using SSL and have provided a matching client certificate
05:14 [oftc2] [notice(NickServ!services@services.oftc.net)] for nickname eightyeight. You have been automatically identified.

Wrap-up
Congratulations! You are now connected securely to OFTC via SSL and you have identified to NickServ successfully with your self-signed certificate. The major benefits of this method, is you can ditch any client-side identification scripts, which is always a bonus. Further, your packets are now encrypted between you and the OFTC servers. OFTC also utilizes server-to-server encryption, so if you’re physically connected to a server in the United States, and someone you’re in private message with is physically connected to a server in Europe, not a single plaintext packet is sent on the wire between your client and his (assuming he’s connected via SSL as well).

A final not on SSL connections, is your computer clock that you are running Irssi on needs to be accurate. It would be recommended to use NTP to keep your clock in sync with Internet time servers. If your clock is too far off, you won’t be able to negotiate the OpenSSL handshake, and as a result, not be able to take advantage of the encrypted traffic. Also, OpenSSL certificates need to be valid. If your certificate expires, then you will not be able to present it to the server, and as a result, not be able to authenticate to NickServ. The dates on expiration are up to you, but validity is important. You can see the dates of your certificate with the following command:

openssl x509 -noout -in nick.pem -dates

Enjoy the security.

Connecting with SSL
Freenode is listening for SSL connections on ports 7000 and 7070, rather than the standard 6697. I don’t know what the logic here is for that, but does it matter? A port is a port is a port. So, for Irssi, setting this up is rather simple.

/server add -auto -ssl -network freenode irc.freenode.net 7000

Boom! Done.

Now, if you want to verify the Freenode server SSL certificate against a certificate authority (CA), then you’ll need to download the CA certificate from the authority that signed the server certificate. In this case, its Gandi.net, and their CA certificate file can be found here: http://crt.gandi.net/GandiStandardSSLCA.crt. However, using the file in its native DER format for Irssi wasn’t working for me. So, using openssl, I converted the binary DER data file to PEM format, at which the Freenode certificate would properly verify:

/server add -auto -ssl -ssl_cacert /etc/ssl/certs/GandiStandardSSLCA.pem -network freenode irc.freenode.net 7000

[freenode] Irssi: Connecting to irc.freenode.net [140.211.166.4] port 7070
Irssi: warning Could not verify SSL servers certificate:
Irssi: warning   Subject : /OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*.freenode.net
Irssi: warning   Issuer  : /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
Irssi: warning   MD5 Fingerprint : F8:40:2C:D9:D6:46:1F:D0:38:5D:ED:21:69:8B:17:C4

2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: unable to get issuer certificate
the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.

/server add -auto -ssl -ssl_verify -ssl_capath /etc/ssl/certs -network freenode irc.freenode.net 7000

cd ~/.irssi/scripts/
wget http://freenode.net/sasl/cap_sasl.pl
cd autorun
ln -s ../cap_sasl.pl cap_sasl.pl

/RUN cap_sasl.pl
/sasl set freenode primary-nick password DH-BLOWFISH
/sasl save
/save

aptitude install libcrypt-blowfish-perl libcrypt-dh-perl libcrypt-openssl-bignum-perl

16:05 [freenode] Irssi: Looking up irc.freenode.net
16:05 [freenode] Irssi: Connecting to irc.freenode.net [140.211.166.4] port 7000
16:05 [freenode] Irssi: Connection to irc.freenode.net established
16:05 [freenode] [niven.freenode.net]: *** Looking up your hostname...
16:05 [freenode] [niven.freenode.net]: *** Checking Ident
16:05 [freenode] [niven.freenode.net]: *** Found your hostname
16:05 [freenode] [niven.freenode.net]: *** No Ident response
16:05 [freenode] Irssi: CLICAP: supported by server: identify-msg multi-prefix sasl
16:05 [freenode] Irssi: CLICAP: requesting: multi-prefix sasl
16:05 [freenode] Irssi: CLICAP: now enabled: multi-prefix sasl
16:05 [freenode] >>> eightyeight!88@oalug/member/pdpc.supporter.monthlybronze.eightyeight atoponce You are now logged in as atoponce.
16:05 [freenode] Irssi: SASL authentication successful
16:05 [freenode] >>> Welcome to the freenode Internet Relay Chat Network eightyeight

16:05 [freenode] >>> CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLMPQScgimnprstz CHANLIMIT=#:120 PREFIX=(ov)@+ MAXLIST=bqeI:100 MODES=4 NETWORK=freenode KNOCK STATUSMSG=@+ CALLERID=g are supported by this server
16:05 [freenode] >>> SAFELIST ELIST=U CASEMAPPING=rfc1459 CHARSET=ascii NICKLEN=16 CHANNELLEN=50 TOPICLEN=390 ETRACE CPRIVMSG CNOTICE DEAF=D MONITOR=100 are supported by this server
16:05 [freenode] >>> FNC TARGMAX=NAMES:1,LIST:1,KICK:1,WHOIS:1,PRIVMSG:4,NOTICE:4,ACCEPT:,MONITOR: EXTBAN=$,arx WHOX CLIENTVER=3.0 are supported by this server

Hilight Window

See the irssi screenshot above. The section labeled “1″ is a split window called “hilight”. Anything that is hilighted (set using the /hilight command) will be logged to that window.

To do this, first load the script. The script I use is a modified version of cras’s hilightwin.pl that logs timestamps as well. It is available here: hilightwin.pl

Put the script in ~/.irssi/scripts/autorun/ and type /run autorun/hilightwin.pl in irssi.

Next, create the split window. This is done with the /window command. See /help window for details on how this works.

  /window new split
  /window name hilight
  /window size 6

The above commands will create a new split window (as opposed to a “hidden” window, which privmsg, channel, and status windows are by default), call it hilight (so the script knows where to send the information) with a height of 6 lines.

Now, have someone address you in a channel using “yournick: hello”. If you did everything correctly, it should be logged to the split window. If you want to have all lines containing your nick hilighted, type /hilight yournick. See /help hilight for advanced features. Use /layout save to save your layout settings and have irssi automatically recreate the split hilight window on startup.

For me, irssi is more than just an IRC client. It’s a complete messaging center. I access IRC, Jabber and push to microblogging sites, such as Facebook, Identi.ca and others. Because I’m running behind GNU screen, I want to be aware of any messages while I’m away. Of course, Irssi does this for you automatically, by putting your hilights in the status window. For me, that’s a busy window, and it’s easy to lose hilights if they sit long enough. So, I’d rather have the hilgihts go to a separate window. Enter that script listed above, along with splitting the window for immediate access.

Now you have a split screen window that your highlighted messages are going to. However, they’re also going to your status window when you’re away. This is known as your “awaylog”. You can change that setting if you want. By default, it logs ‘msgs hilight’. If you want to disable it, now that you have a new hilight window, you can set:

/set awaylog ""

Note, that your new hilight window will only log hilights, not msgs. For me, this is no big deal, because msgs are already in their own window by default anyway, and the point of this is to keep all the messages in one place. So, this is a win/win for me.

Along with this script, there is other script goodness that I take advantage of with this fabulous client. Listed below:

• anames.pl- Query the server to see who is away and who is not by running /anames. Prints out a list similar to /anames, but gives those whore are marked as away a different brightness to their nick.
• il.pl- Because I’m a microblogging nerd, I like to know in my status bar how many characters I’ve currently typed before I hit enter, to know whether or not I’m under the 140 character limit. Works like a charm, character-by-character.
• trigger.pl- This script rocks! Allows me to do search and replace with text in my client. I use it mainly for the Identi.ca Jabber bot. See this post for more details.
• usercount.pl- You can put the number of people in a channel, including the number of ops, halfops, voices, etc in your status bar.
• trackbar.pl- This puts a trackbar on your window where you last were in the conversation last time you were watching it. Very useful to pick back up where you left off in a conversation when you return to that window.
• screen_away.pl- Using GNU screen is solid with irssi. However, when I am away, I want to mark myself away with the server. So, all I have to do is detach screen, and this script will mark me away with my configured away message. No public announcements either.

Of course, I use a few others, such as the bitlbee scripts, but these are the heavy hitters. Must-haves for any serious irssi user/hacker.

First, I wanted to change my personal “business” card (referred to as a “personal card” from here on out). My initial personal card was an Ubuntu one I had printed after becoming an Ubuntu Member. I ordered 2,500 of them a couple years ago, and I’ve handed just about every one of them out. Rather than reorder a new batch, I wanted something more generic than just targeting Ubuntu. Further, I wanted to take advantage of technology.

When Google changed their front page logo to a bar code on October 7, 2009 to celebrate the approval of the bar code patent, I spent a great deal of time on Wikipedia learning about bar codes. I knew there was a quite a few out there, but I wasn’t aware of all the types, how the encoding was handled, and so forth. In the process, I discovered QR Code.

QR Code appealed to me for a few reasons. First, although a patented technology, it’s royalty-free and the patent owner has promised to not exert patent rights on it. This is the same case as with Ogg Vorbis. So, although not truly an “open format” in the pure sense of the word, good enough for me. Further, there is a an application called “qrencode” that is Free Software and available an most GNU/Linux operating systems. So, this makes it easy to create your own QR codes. Second, the technology behind the QR code is rather slick. It contains error correction, should up to 30% of the code be damaged or unreadable. It can be scanned any direction in 360 degrees for bar code scanners. The density is high enough to store up to 7,000 characters. More features can be found on the owner’s page.

Immediately, I saw this as an opportunity to encode my contact information. This would be a great way to put your name, web site, email, address, telephone number, and other useful information in a compact space. I could see putting this up on web sites to avoid email harvesters (although it’s only a matter of time before they are smart enough to decode QR codes). Then I thought, why not put it on my personal card? The only thing that was preventing me from doing so was an efficient way for a contact who receives my card to get the data out of it.

At the time, the only decoder I was aware of was the ZXING site. You gave it a URL path to a QR code image, or uploaded your own, and it would decode the information. I didn’t want people scanning my personal card to an image, then uploading that image to the site. There has to be a better way. So, I started browsing the ZXING site a bit, and I learned that it’s an Open Source project for creating a bar code reader. The project is hosted on Google Code, and I found that there is a Blackberry, iPhone and Android app. SWEET!

So, now people can install the free app on their phone, scan the image, and parse out the contact information. The only problem that I saw at the time, is even though they can scan the QR code, and decode the data, the app just presents the user with the raw data, with no ability to add that information to their address book. So, my quest continued. Surely, there must be a way to get the contact information out of the QR code, and into an address book. So, back to web to found out how.

Needless to say, it didn’t take long at all before I learned about MECARD. You can think of MECARD as a light version of vCard. Essentially, a single line of text contains all the meta data and appropriate information for populating an address book. Info such as name, address, telephone, email, URL and more. Further, the ZXING app supports parsing MECARD data, and adding that data to your address book!

At this point, I was satisfied. I’m ready to build my own QR code, and put it on my personal card. Well, almost ready. I wanted one extra step before I was ready to commit my personal card to the printer. For the URL in my MECARD, I wanted it to point to additional contact information that could also be parsed using computing for adding to an address book, whether it be on a mobile phone or an email address book, such as in Mozilla Thunderbird or Outlook, or even online, like with Google Contacts. So, I spent more time searching the web, finding a way to get all this integrated.

It wasn’t long before I found hCard. hCard is an HTML version of vCard. It’s a microformat for embedding HTML into a web site, so applications, just as JavaScript or Firefox extension, can parse the data, and populate an address book with the appropriate entries. The whole point is to keep the contact from entering in the contact information by hand. Otherwise, I just would have printed the raw ASCII on the personal card. No, I want to fully automate my contact information from head to toe taking advantage of mobile phones and other technology. So, hCard fit the bill.

I began populating my own hCard to put on my main site, then the URL in my MECARD would point the user that direction. However, I found that my Google Profile already supports hCard, FOAF, XFN and other standards. So, for me, it made sense to point people that direction rather than build my own. However, after having my QR Code created with everything I wanted, and pointing them to the right URL, and getting the cards printed, I found that Google isn’t exporting email address, URL, telephone, or other information that hCard supports in the HTML. I’m a bit disappointed by this, and I wish I would have paid closer attention, but I guess it will have to work for the time being. I’m hoping that Google adds this data to the hCard export, so I don’t have to change my personal cards in the near future.

Now, the personal cards themselves. I wanted to go hard core, relying 100% on technology to parse the data rather than a human. So, I put just the QR Code on the “front” of the card, with no alphanumeric data anywhere to be found. On the back of the card, I put the glider image, a fanboy icon for the hacker culture and ethic. That’s it. An image on one side and an image on the other. The personal card itself has no rotation and should you have a smart phone with a bar code reader, it should be trivial for you to get out the contact information, and populate your address book.

This is a trial run. I don’t know what will happen or what will come about as I start handing out this card to people. Time will tell. It should be interesting though, and I’m sure it will be quite the conversation starter. Here’s to risks.

The idea is simple. On Fedora and SUSE based operating systems, if /etc/cron.allow AND /etc/cron.deny do not exist on the system, then only the super-user can install cron jobs using the crontab command. However, on Debian and Ubuntu, both files are missing, yet everyone on the system can install a cron job. So, the question was: why does Debian and Ubuntu feel the need to be different from everyone else? Why do they need to deviate from standard practice?

Now, for the record, I don’t care if Debian deviates… much. Debian is an operating system. Sometimes, I think those in the Free Software and GNU/Linux world forget that. Operating systems are free to make the changes necessary for their platform as they see fit. Those changes will likely either make users happy and make the operating system popular, like Ubuntu, or they won’t be good changes, and likely will lose users, like, well, Gentoo (sorry guys, but you have seen better days). I’m all for changes that are thought out and that bring obvious or non-obvious benefits. For example, Debian Squeeze moving away from System V Init to Upstart.

So, the question remains: Is Debian deviating with Vixie cron from what would be considered “standard practice”? Well, to start, I pulled up the crontab(1) man page to see what it says regarding the matter. On Debian, this is what I found:

If the /etc/cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. For standard Debian systems, all users may use this command.

I pulled up the same man page on Fedora, and this is what I found:

If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file does not exist but the cron.deny file does exist, then you must not be listed in the cron.deny file in order to use this command. If neither of these files exists, only the super user will be allowed to use this command.

Both man pages document exactly what the behavior of crontab is should both /etc/cron.allow and /etc/cron.deny be missing. Further, the crontab(1) man page mentions a site-wide configuration file for this behavior. On Debian, by default, I reached for /etc/default/cron to find this configuration. Nothing in there seemed to lead me to this behavior. Pulling up /etc/sysconfig/crond on Fedora also lacked the information I was looking for. I dug through /etc/pam.d/cron, /etc/crontab, /etc/init/cron, /etc/init.d/cron, /etc/security/access and just about any other possible configuration file that might be related, and came up empty-handed every time.

So, when in doubt, Use the Source Luke. So, I went to the Debian packaging site to grab the cron source. Why there rather than upstream? Because Debian ships the upstream pristine source in one tarball with the Debian-specific patches in another tarball. This way, I can see what is being patched while staring at the source directly. While I was at it, I grabbed the source RPM from Fedora as well. However, I grabbed it from Fedora 8, as it seems Red Hat has forked Vixie cron to “cronie” around Fedora 9, and I wanted to compare apples to apples.

Now, before I dug through the source, I found one bit of information that actually started laying to rest my suspicions. Paul Vixie developed cron for BSD 4.3. So, I would imagine that Vixie cron is still running on BSD systems, and that the default, intended behavior from Paul Vixie himself would be present on the BSDs. Curious, I fired up FreeBSD, and read the crontab(1) man page:

If the allow file exists, then you must be listed therein in order to be allowed to use this command. If the allow file does not exist but the deny file does exist, then you must not be listed in the deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. The format of these files is one username per line, with no leading or trailing whitespace. Lines of other formats will be ignored, and so can be used for comments.

Interesting. Even FreeBSD says that depending on site-wide configuration parameters, either only the super-user will be able to use crontab or everyone. This is the same wording in the Debian man page. Curious, I looked, and sure enough, both the allow and deny files are missing in /var/cron/, and yet everyone on the system can install cron jobs. This is telling me that Debian is not deviating from upstream, and that Red Hat is. However, I have the source, let’s see what that says.

First, I cracked open the Fedora patches to see if the patch was obvious. To be honest, I was a bit overwhelmed by the sheer number of patches Fedora was applying. Most were for PAM and SELinux, however. But, there was a patch for the crontab(1) man page, and there was a patch against crontab itself. After a bit of digging and parsing the C files, it seemed clear to me that Red Hat was patching crontab to only allow root to install a cron job if both the allow and deny files are missing. This patch does not exist in Debian, nor could I find it in FreeBSD.

So, it seemed clear. Debian was in fact not changing the default behavior of cron, but it was Red Hat who was doing the changing. Further, despite what the documentation says, I could find no site-wide configuration file to modify this behavior- even referenced in the source code. The only way to make the change was to change the code before compilation (so maybe we should submit a bug on the man page).

Digging deeper, I learned that there are many cron systems available for GNU/Linux. It appears Arch Linux is shipping dcron by default (Dillon’s cron), Red Hat has forked Vixie cron to cronie, and Debian and Ubuntu both utilize or will utilize Upstart, which will eventually replace cron entirely. It’s my understanding that launchd on Mac OS X has also replaced cron (although I haven’t verified).

Generally, when I got into discussions with various people about Debian or Ubuntu changing this, that or the other for whatever reason, nine times out of ten, it has been my experience that Debian is not the one deviating, but it is the one who is doing the accusing that is deviating. This example with cron has only been one. I’ve had discussions like this many times before. The only real solid example of Debian deviating from standard that I can come up with quickly off the top of my head, is Apache. The /etc/apache2/(sites,modules}-{available,enabled}/ directories are a break from standard. However, I have found that I prefer this configuration to upstream vanilla, as it makes administering specific modules and websites a bit easier to maintain without affecting others. This is a change that is long term beneficial to Debian.

In conclusion, what does this mean? Is Debian better than Fedora/RHEL/CentOS or any other operating system? While I prefer it on my systems, the answer is of course no. But, when breaking from standard practice is called into question, I’m glad Debian sticks as close to upstream as possible. I understand the need for patches where appropriate, but I would prefer as vanilla as possible so I’m not a fish out of water when I need to move to another operating system that is deploying the same technology. At least from that point I’ll be able to see the changes the new system is making. I understand Arch Linux is about as vanilla as you can get, but until they separate the non-free from the free software and GPG sign their packages, I won’t run it.

Debian it is for me, and I’m glad they have the philosophies they do.

First, a disclaimer. This post is not meant to be a sure method for defeating attackers. Rule number one in computer security is that if an attacker has physical access to your machine, all bets as to data integrity and physical safety are off. However, than doesn’t mean that you can make the process so tedious and time consuming for the attacker, that he will likely not bother and move to another victim. This post is about those methods. If they’re going to attack you, why not at least make it challenging for them?

If you have the ability, this post requires wiping your disk by starting from scratch. So, if you have data on that disk, you should probably back that up first. If it’s a new laptop, and you’re not invested into the operating system, then maybe you don’t need to worry about it. Just realize, that from this point on, if you decide to “follow along” with your own equipment, this will wipe your data, and if you didn’t back up your data first, you’re the moron, not me.

Okay, with that out of the way, shall we continue?

Step One: Prepare your hard drive.
The goal of this step is to install an encrypted filesystem. So, before we do that, we need to do some preparation. In order to get to that point, you will need to write random or pseudorandom data to the entire disk. This will take some time. My experience has show that laptop drives usually operate around 30MBps, so if you have a 300GB drive, this will take you just under 3 hours. The reason for doing this is to confuse the attacker just exactly where the encrypted filesystems reside. If the entire disk is underlined with random or pseudorandom data (it doesn’t necessarily need to be cryptographically secure here), then when looking at the drive level, it will be practically improbable to determine where the encrypted filesystem starts and where it ends. If you skip this step, then it’s quite obvious, and rather than wast his time on the entire disk, the attacker can focus his efforts on just the obvious encrypted portions of the disk.

Now, some tools for installing encrypted filesystems will already have this step built in, such as the Debian installer, but some won’t. You’ll need to discover your vendor’s documentation to see if this is the case. I would say it doesn’t hurt to be safe, and take this step anyway, but it’s up to you.

There are many utilities for writing random or pseudorandom data to the drive. Probably the best tool will be DBAN, or Derik’s Boot and Nuke. This utility is generally used for destroying data, but in this case, we’ll use it for preparing data. Download the live CD, burn it, and reboot your machine. I would recommend selecting the “PRNG Stream” from the menu. This will normally write pseudorandom data to the disk 4 times. However, it shows a progress report on the number of passes, so after it completes its first pass, you can reboot. It’s important to note that selecting “Quick Erase” will do a single pass of zeros. This isn’t what we want. We’re trying to deter attackers by not giving them the boundaries of our encrypted filesystems. If you choose “Quick Erase”, then you’ll be clearly showing them where those boundaries exist. As tempting as it may be, don’t select it.

If you’re familiar with Linux live CDs, you can boot into a live environment, such as KNOPPIX, pull up a terminal and run the following, assuming the drive you’re preparing is “/dev/sda”:

dd if=/dev/urandom of=/dev/sda

The point is getting random or pseudorandom data down on the entire disk. However you accomplish that, is up to you.

After a few hours pass (depending on the size of your drive, and if you cancel the operation after a single pass of PRNG Stream), you are now ready to reboot into your operating system installer if it provides the ability to encrypt the filesystems, or into a separate utility for doing so.

Step Two: Set up volumes or partitions and encrypt
With the Debian installer, and most GNU/Linux installers, you can set up your partitions or logical volumes, then tell the installer to encrypt them, even with some options on the cryptography. When you’ve defined your filesystem boundaries (I’m not going to cover that here), and you’re ready to encrypt, you’ll inevitably be required to type in a username and passphrase. Some encryption utilities will use this passphrase as a seed for the encryption algorithm, so the stronger the passphrase, the stronger the seed, and this the more unlikely an attack will be successful on the filesystem. So, choose wisely and choose securely.

Step Three: Install the operating system
Whether it be Windows, Mac, Linux or whatever operating system that supports encrypted filesystems, you’re now ready to install it. Follow the operating system’s installer to the end, reebot, and make any additional final preparations to your computer before putting down the data. You should at this point be able to boot the computer, provide the necessary username and passphrase, and use your operating system as normal. If not, you’ll need to spend some time with your operating system’s documentation or encrypted filesystem documentation to get to that point. This post isn’t about that, so Google might be your friend here.

Okay, so now we have a usable operating system running on top of a fully encrypted drive. If we were to stop here, we wouldn’t make things very challenging for the attacker. We want to do that. So, we’re going to start adding some hurdles along the way. If the attacker has the stamina, then so be it. I’m guess that most attackers, when faced with each of these hurdles, likely won’t bother, and move to their next victim, rather than waste time trying to figure out how to get from Point A to Point B.

Step Four: Password protect your BIOS
This will vary widely on hardware, so consult your vendor’s documentation on how to boot into your laptop BIOS and set an administrator password. However, this functionality should be provided on most modern BIOSes. When found, go ahead and set the password. It can be whatever you want. I would recommend making it hard to guess, but it doesn’t really need to be on the same level as the encryption passphrase you provided earlier. Just don’t make it successful to a dictionary attack, and you should be good. Don’t reboot. Stay in your BIOS for the next step.

Step Five: Change your boot order to boot off the hard drive first
The reason for setting the administrator password in the BIOS was so we can tell the BIOS that we always want it booting from the hard drive first, rather than from the floppy, CDROM, network or USB. This step is necessary to hopefully avoid the Evil Maid attack, something I’ve already blogged about here. In summary, the Evil Maid attack is booting your computer from a USB or CDROM, replacing your bootloader by installing a custom bootloader with a keylogger, and powering down. Then, when you boot your machine, and enter the encryption passphrase, it gets stored on disk, or sent over the network to a remote server. After you leave your laptop a second time, the attacker comes back to your computer, boots off the hard drive, provides the newly discovered encryption credentials, and steals your data.

So, if your laptop is BIOS password protected to only boot from the hard drive, this is a good deterrent. Why? Well, in order to remove the password off the BIOS, so the attacker can boot from some other medium, they will need to disassemble the laptop to get to the motherboard, and flash the BIOS. This is easier said than done on laptops. Have you ever taken your laptop apart? I have. I’ve take apart both my old HP Pavilion and my current ThinkPad T61. They’re a royal pain, and extremely time consuming.

A good attacker will be paranoid for time. They don’t want to get caught. If it means spending 3 hours disassembling a laptop just to flash the BIOS, so they can install their custom bootloader and keylogger, chances are high he’ll move on to another victim. Now, that’s not to say that every attacker can’t do this, or they know they have the time, and your data is that valuable to them. Maybe the attacker is skilled at disassembling Dell, Lenovo and HP laptops, so it’s only a 30 minute inconvenience that he knows he can make. But, maybe not. At least this is a moderately challenging task, and I’d be willing to bet most attackers won’t bother.

Step Six: Physically lock down your laptop or take it with you
Again, just another deterrent, but locking your laptop down to a secure location could provide enough of a challenge to deter physical theft, should all efforts being made at getting to your data fail. After all, there is value in the hardware itself. EBAY is probably making a killing of such scenarios without knowing specifics. This doesn’t mean the attacker isn’t skilled at lock picking or doesn’t have a strong set of bolt cutters with them. However, if the time it takes to remove the laptop from the premises is a challenging effort, the attacker likely won’t bother, and move on.

With that said, I had my car broken into once. They were after my stereo. Thankfully, they were caught in the act, and found guilty in court of seven counts of theft and property damage, among other things. However, in the car before mine, they couldn’t successfully remove the deck from the dash. It was bolted down. So, out of frustration, they physically destroyed the deck and the dash. Not out of failing to remove it, but out of anger for not succeeding. Your laptop may fall victim to such physical damage.

So, if you can carry it with you, you probably should. When I was on the road, I took my laptop with me everywhere I went for fear of physical damage or theft. I would take it with me to dinner. I would take it with me to events. I would take it with me sight seeing. I was paranoid. Sure, I run the risk of damage while traveling with it, but I know how to treat my bag carrying the laptop. At least then I’m somewhat in control. Further, an attacker can’t attack what isn’t there. But, when I couldn’t take it with me, I would lock it down securely, and hope it remained in tact when I returned.

Step Seven: Remove the data and/or encrypt it a second time
Many operating systems support encrypting directories and files on top of the filesystem itself. This means you can have an encrypted directory in your home folder, where the valuable data resides. Should the attacker successfully get access to your encrypted filesystem, if you chose a different passphrase for your encrypted directory, hopefully, they won’t get access to that.

But, keeping that sort of sensitive data on the drive might not be wise, even if it is encrypted. So, it would be best to have that data on an encrypted USB disk. Your only concern should be making sure you don’t lose that drive. Even if it’s not stolen data, lost data still sucks. Backups here help.

At my place of employment, we’re developing a virtualization solution where all the developers will have virtual desktops in our datacenter. The idea is to keep the data off of the developer’s laptop. So, when they login to their laptop, they then must login to the VPN, then use RDP or SPICE (yeah, we’re deploying RHEV) to login to their remote desktop, and work from there. At this point, the laptop becomes a mere dummy terminal, not storing a single piece of data- even email. There are concerns, like if the developer doesn’t have Internet access, or if the datacenter is compromised, but from a traveling perspective, keeping the data off of the traveling laptop is a net win. Some hotels might have crappy WIFI, but at least security has come first, and the data is safe.

Appendix A: Learn how to remove and restore your bootloader
This is a crucial skill, I think. It doesn’t really fit into the above steps per se, so I’ve added it as an appendix. The idea is simple. When traveling from another country to the United States, the Department of Homeland Security thinks it’s fun to ignore the Constitution, and seize and search your laptop without a warrant. Bruce Scheier has covered this extensively, so I’ll let you read up on his posts about the topic. If you’re running an encrypted filesystem, they can detain you until you provide them with the passphrase, at which point they can then image your drive, keeping your data. This is wrong on so many levels, but you have a good deterrent- wipe your bootloader before landing.

When I traveled to Canada for training, I was already aware of the DHS doing this at customs. So, before being required to turn off my laptop during landing, I wiped the bootloader, and prepared a script in my mind should the DHS want my to power on my laptop. I was resolved that I wouldn’t lie, as that would be perjury, but I would dance around the issue as best I could. The script would go something like this:

Agent: Can you power on your laptop please?
Me: Sure, but while on the road, something happened, and it will no longer boot. It says it’s missing an operating system. I’m hoping to get it fixed when I get back to the office.
Agent: Will you power it on anyway please?
Me: Sure.
(I power on the computer, at which point, it behaves exactly as described.)
Agent: Okay, thank you. Carry on.

When I was returning from my Canada trip, and passing through customs, the agent asked me to remove the laptop from my bag and open it. I was already prepared with a removed bootloader, and my heart was racing to go through the script. When I opened the laptop, we proceeded to swipe it looking for traces of explosives. When he was satisfied, he said thank you, I put the laptop back in my bag, and was on my way. I was a bit bummed that I didn’t get to defeat the DHS at their own game, but was relieved at the same time that I didn’t miss my flight home.

After I was on US soil, I boot off a rescue CD, and restored my bootloader, and was able to boot back into my Debian install without trouble. This takes some practice and know-how, but I think it’s really quite worth it should that scenario ever present itself. Of course, who knows what would happen? Maybe I would be detained until they could fix the problem with my laptop, at which point, I would still be required to turn over the passphrase, and they image the disk. Who knows? Still worth a shot, and it’s easy to do, if you know what you’re doing. Just don’t lie.

Appendix B: Stay with your belongings through metal detectors
Again, this is something that doesn’t really fit in the steps above, so it’s in the appendix as well. When you are entering an airport, and your belongings have to go through XRAY, there is an attack to steal laptops that is rather trivial and easy to setup. All it requires is three people- two attackers and the victim.

The attackers find a victim with a laptop (or bag obviously carrying a laptop) they want. They both position themselves immediately in front of the victim when standing in line to go through security. By the time the first attacker reaches the metal detector, the victim has likely placed their personal belongings on the belt to go through the XRAY machine. The first attacker goes through the metal detector without a problem. He waits at the end of the conveyor belt to get his belongings as well as snatch the laptop. The second attacker, however, causes problems going through. Every time he attempts to go through, something in his pockets, or otherwise, causes the detector to go off. Now, generally, it only takes 2 or 3 attempts before the agent will just get his magic want, and swipe him down from head to foot. But, two to three attempts is all the time that is needed for the victim’s bag or laptop to go through XRAY, at which point the first attacker takes the computer, and disappears into the crowd before the victim even had an opportunity to get through. It’s sneaky, it’s effective, it’s fast and it’s clean. Further, TSA isn’t keeping track of who’s belongings belong to who. For all they know, that was their laptop, not yours.

How do you avoid this attack? When I traveled, I stood at the XRAY machine with my hand on my laptop bin, and I sent it through the same time I went through. I never gave it a chance to get ahead of me. This would slow down the line a bit sometimes. In fact, I would let people go ahead of me while I waited. I took no chances. I’ll go through metal detection faster than my laptop will go through XRAY, so I can wait for it to come down the belt right into my own hands. It requires a bit of patience and stubbornness, but I think it’s worth it. You’ll likely not bump into the cranky people behind you again, so no biggie.

Conclusion
So, there you have it. Those are the procedures and steps I would take when traveling with my laptop. I would recommend the same to you. Really, it boils down to determination, knowledge and a bit of luck. You can avoid the worst if you are sufficiently paranoid. There’s nothing wrong with taking the extra precautions to protect your data and your laptop from theft or damage. Of course, these steps aren’t bullet proof, and everything comes at a cost. There might be a slight inconvenience to the traveler to jump through some of these hoops. But, what is it worth? If the cost of the inconvenience outweighs the cost of the data, then some or all of these steps might not be necessary. If the cost of the data outweighs the cost of the inconvenience, then I would say stick to each step religiously. That’s just me.

Inevitably, I would be asked what the meaning of “su” really stood for. This seems to be the Great Question in Unix (aside from the creat() command in C lacking an ‘e’). When I first started with Unix back in 1999, I was always under the impression that “su” meant “super user”, as the only time I ever used the command was to become root. My learning was on Solaris 7, and even my colleagues agreed that “su” meant “super user”.

After discovering Linux, and having it installed as a virtual machine on my own hardware (yes, VMWare existed back then), I started tinkering, and I found that you could use “su” to switch to more users than just root. This shook the very foundation that I had learned Unix on. So, what does “su” mean? After browsing the man page, and spending a great deal of time on mailing lists and web forums, I was convinced that “su” stood for “switch user” or “substitute user” rather than “super user”.

Further, upon learning “sudo”, it further cemented that ’su’ meant “switch user”, as “sudo” meant “switch user and do”. After all, “sudo” could be used to switch to any user on the system, not just root. So, as far as I was concerned, “su” meant “switch user” and “sudo” meant “switch user do”. Case closed.

Or was it?

A year or two later, I took a Unix interprocess communication course at my local university. Solaris 8 had released, and we were doing our coursework and lab work on those machines. When covering fork() and exec(), my professor taught “su” from the standpoint of it creating a subshell, and showing the parent/child process relationships. This got my mind thinking. Does “su” come from the first two letters in “subshell”? After all, you can “su” to yourself, which means you’re not really switching user accounts, and you’re not becoming root. I had to know. After class, I asked my professor what “su” meant, and sure enough, he sad “su comes from the first two letters of ’subshell’”.

There you have it. “su” means “subshell”. So, “sudo” must mean “subshell do” for the same reasons that you can “sudo” to yourself, just as you can with “su”. To me, this was the most complete definition of the term. It couldn’t get any more complete than that, and when teaching, I taught my students that very thing, usually stating that “su” could mean “super user”, “switch user” or “subshell”, with my preference and belief on the last definition.

This morning, I had another foundation shaking moment with the meaning of “su”. I found some old Unix source code, where su.c was available. Curious, I looked at the source. What did I find?

What is the first comment in that C file? “/* su — become super-user */”. “su” was written to only change to the root user on the system. It wasn’t designed to switch to any other user that has an account. “su” meant “super-user”. I need to sit down for a second.

The code above comes from the fifth edition of Unix by Dennis Ritchie and Ken Thompson. If you know your Unix history, it really wasn’t until the sixth edition that things really started taking off for the Unix world. So, it’s safe to say that most, if not all, of the code in the fifth edition and prior were written by Dennis and Ken themselves. Fifth edition Unix released in 1975, so it doesn’t get much more authoritative than that.

“su” can do so much more than Ken and Dennis implemented back then, as already discussed. Surely, the definition of “su” has changed, at least a little? I would hope so. The great thing with human language, is it is dynamic and flexible. We, as a society decide what meanings we put to our words, so as far as we are concerned, “su” could mean so much more than “super user”. We can define it to mean “switch user”, “substitute user” or “subshell”. Or, we can be stubborn, and hold to the old definition from 1975 that “su” means “super user”.

So, where does that put us today, 34 years later? Well, I wish I had an answer, but I don’t. However, knowing your Unix history (yes, there was Unix before Linux) shows maturity on your part. Knowing that initially “su” was used only for becoming the root user will show others that you are somewhat educated on the topic.

Really, though, the definition doesn’t matter all that much, does it? If it means “super user” or “subshell” or anything between, what matters is what you can do with it as a user or administrator. As for me, I like updating the definition to “subshell”, but at least I can discuss it at length with another because I know my history.

Why is this a problem? Well, when booting Debian in VirtualBox, it wants to mount the volumes (just a file residing in Windows), but the last mount date timestamp shows a date in the future. This is because I’m 7 hours behind UTC. So, on every boot, I am dropped to an sulogin prompt, where I need to provide the root password to fix the system. Because the last mount date timestamp is in the future, I need to run:

# e2fsck -fy /dev/work/root

This will update the timestamp to the current hardware clock time, at which point I can reboot, and remount the drives. However, when init is loaded, it executes /etc/init.d/hwclock.sh. This script either sets or does not set the hardware clock based on a setting in /etc/default/rcS. Pulling up the file, this is what I found:

#
# /etc/default/rcS
#
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" package.

TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes
VERBOSE=no
FSCKFIX=no
RAMRUN=no
RAMLOCK=no

Notice the setting “UTC=yes”. This means to change the hardware clock to UTC time when booting. Of course, this also means setting the timestamp on the mounted filesystems to the UTC date. Because Windows is my host operating system, I don’t want to do this. So, changing the value to “no” fixes the issue I’m having with the last mount time on my volumes being in the future. I probably should have mentioned that this init system is good old fashioned SysV Init. I haven’t upgraded to Upstart yet, although that’s on the TODO. I’m not sure how this post would change with Upstart in the picture, but when I upgrade, I’ll likely post the solution if I’m faced with the same issue again.

Hope this post helps someone in the future who has also had this problem.

You now have the following variables available in the shell script namepace: RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, BLACK, WHITE, BOLD_RED, BOLD_GREEN, BOLD_YELLOW, BOLD_BLUE, BOLD_MAGENTA, BOLD_CYAN, BOLD_BLACK, BOLD_WHITE, RESET. Using these variables, you can manipulate the output from “echo” and “printf” for your script. For example, here’s a screenshot using “echo” to print red, green and blue text to the screen. Notice that I’m using the “RESET” variable after the blue text to reset my prompt text back to normal. This may or may not be necessary, depending on how you configured your prompt, but it’s not a bad habit to get into.

Thought this might be helpful to the larger scripting community or for those sysadmins, such as myself, who would like a little variety added to their script output.