Introduction to command line IM and Bitlbee

Bitlbee is a way to bridge IM and IRC together essentially allowing you to connect to your IM network through an IRC interface.  One great feature of Bitlbee is that it supports a large number of different protocols (including Gtalk, Yahoo!, Facebook and Twitter), which happen to be nearly all the major platforms I’m concerned with, excluding Microsoft Lync.  The main reason I want to discuss Bitlbee now, ahead of time, is because I will be doing a series of posts that specifically tie Bitlbee in with a few of the more popular IRC clients.

As you will see, there are slight differences in how Bitlbee behaves inside each of the IRC clients I have been trying out, I will leave these details out for now to make things easier to follow.  Today’s post will be more guided towards general use of Bitlbee, so I will be going over things like how to get around and its basic usage.

As usual, I will be running in Ubuntu so these instructions are specific to Debian based distros.  Outside of installation, I image the usage will be very similar in other distributions because most of the commands and configuration are happening inside Bitblee.

Getting used to Bitlbee

Let’s start off by getting Bitlbee installed.

sudo aptitude install bitlbee

Now let’s go ahead and add in our gtalk (jabber) account.

account add jabber account.name@gmail.com

Set up correct port and ssl for gtalk.

account 1 server talk.google.com:5223:ssl

Optional – turn on oauth (Still having some issues with this one).

account gtalk set oauth true
oauth = 'true'

Log in to Gtalk.

account jabber on

Start a chat in a new window.

/msg NickName Hello!

Getting a listing of various IM accounts.

account list
account list online
account list all

Managing various IM contacts, pretty self explanatory.  Here 0 is the gtalk account we added earlier, contact@gmail.com is the person we are adding to our account and nickname is how they will show up in our contact list.

add 0 contact@gmail.com nickname
remove nickname

If you have anything else to add I would love to hear it.  I’m still playing around with the oauth stuff, so I will update this post later with a fix.

Resources:
http://510x.se/notes/posts/Install_and_setup_BitlBee/
http://static.quadpoint.org/bitlbee-user-guide.html
http://wiki.bitlbee.org/Commands

About the Author: Josh Reichardt

Josh is the creator of this blog, a system administrator and a contributor to other technology communities such as /r/sysadmin and Ops School. You can also find him on Twitter and Facebook.

Project: Document Storage Made Simple

I’ve recently identified a need to setup a means of indexing and browsing documents. This is a great little project to demonstrate how we can tie lots of tools together with Linux, so I’m going to write up what I’m doing as I go along.

The needs are pretty simple, but I haven’t found anything out of the box that suits. In particular, I’ve got the following needs:

  • This is only for a couple of people, it doesn’t need the complexity associated with a full-blown document management system.
  • It does need to index PDFs – including PDFs that have been generated from scanned in pages rather than from an office suite.
  • Scanned PDFs may not have had any sort of OCR process applied to them – but that doesn’t mean I don’t want to be able to search for them!
  • It needs to be able to do this with minimal interaction – as a rule of thumb, if it’s even conceivably possible to automate part of the process, that part of the process must be automated. I can think of better things to do with my time than click “Next…”
  • Must be able to interact with the system via a web browser.
  • Anything running on the public Internet is out – most of the information I’m scanning in has no business being anywhere near the public Internet.
  • Must be dead easy to backup. Anything that involves databases, Tomcat etc. is probably far too complicated.
  • Budget: About £250+VAT for a MFD that has a duplexing scanner unit. Other than that: £0. Most multifunction devices come with software that will OCR scanned files and index them, but further investigation suggests it usually fails the web-based and the “minimal interaction” requirement. I have a spare computer I can use sitting around, but I can’t justify a fortune on software. That may change in the future, but it’s what we’ve got now.

So, here’s the question: Can I do it? Read on….
Read more »

About the Author: James Cort

James Cort is Managing Director of Bediwin Information Services, providing IT management and integration services in the South West of England.

Protip November: Quickly check installed packages in Debian

If you ever need to know if a specific package or a specific piece of software has been installed on a Debian system there are a variety of ways to tell, as you are probably aware of. One way that recently caught my eye, which is fast and easy to check from the command line is the search feature of aptitude.

Now, without speaking on the merits of using aptitude for package management (this is an entirely different topic) I would just like to mention here that it (aptitude) needs to be installed for this method to work. If you don’t have it installed already, it’s super simple.

sudo apt-get install aptitude

Okay, with that piece in place we just need to check that the package we are looking for is installed.  So to do that, enter the following command.

aptitude search '~i' | less

Basically, this command will output a list of installed packages.  I just added the | less to easily be able to scroll through the packages.  In my opinion, the flexibility and usefulness of the search feature on its own is  probably enough to start using aptitude, although this can be done similarly with apt-get. You may notice an “A” next to a number of these installed packages.  This indicates that a package was automatically installed.

If you take a look at the output from this command it will look similar to the example posted below.

As I said, this is a quick and dirty way to view installed packages, but there are definitely other ways to go about this.  I was unaware of the search functionality and well, I like aptitude so I thought that I would share the knowledge.  Let me know if you know of any other cool and/or easy ways to check for installed packages.

About the Author: Josh Reichardt

Josh is the creator of this blog, a system administrator and a contributor to other technology communities such as /r/sysadmin and Ops School. You can also find him on Twitter and Facebook.

The power of “Why?”

I’m going go steer away from the very technical “how-to” type things I’ve written in the past and instead give a little bit of job advice to anyone who finds themselves in a technical role for the first time.

Sooner or later, we all have to deal with technical support-type questions.

It’s very tempting in these cases to take everything you’re told at face value and ask simple yes/no questions for more detail. On the face of it, this makes some sense – they can be easy to understand, quick to answer and get you to the root cause very quickly.

I would argue that they’re terrible questions. Yes, sometimes you get useful answers, but as often as not you get:

  • Answers that are downright wrong. Maybe the customer misunderstood the question, maybe they didn’t understand it at all but were afraid to admit ignorance. 
  • Answers that aren’t wrong, but aren’t terribly helpful.  Example: “No, I haven’t seen any error messages” (but considering my computer hasn’t actually got as far as logging me in that shouldn’t be terribly surprising).
  • Drawn into an argument. Example: “I’ve already told you what the problem is, now are you going to fix it?!”
Instead, try “Why?”. “Why do you think you’ve got a virus?” “Why are you having trouble with the website?”. It forces your customer to elaborate and drastically reduces the risk of confrontation.

 

About the Author: James Cort

James Cort is Managing Director of Bediwin Information Services, providing IT management and integration services in the South West of England.

Make MacVim’s mvim script use tabs and play nice with the command line

tl;dr: Replace the mvim script with this modified version: https://gist.github.com/3780676

MacVim comes with a really sweet script called mvim, which lets you launch MacVim and edit files from the command line. Unfortunately, this script is a little weak in a few ways:

  • It doesn’t let you edit multiple files.
  • It doesn’t let you pass in command line options.
  • It doesn’t let you use new tabs for opening new files into an existing window.
  • It doesn’t let you pipe stdin into vim for viewing (great with diffs).

All those things are awesome, so let’s make the mvim script better! How do we do that?

Well, first we add some extra command line options parsing to detect if we’re in diff mode, if we’re using stdin, and to preserve options for passing back into MacVim later. At Line 60 we add the following:

# Add new flags for different modes
stdin=false
diffmode=false
# Preserve command line options lazily
while [ -n "$1" ]; do
  case $1 in 
  -d) diffmode=true; shift;;
  -?*) opts="$opts $1"; shift;;
  -) stdin=true; break;;
  *) echo "*"; break;; 
  esac
done

This is a pretty normal bash argument getting loop. We look for -d (diff mode) and – (stdin) separate from other arguments. We also need to modify the command that starts MacVim to handle our different modes, etc. So we replace that command (originally on line 69):

# Last step:  fire up vim.
# The program should fork by default when started in GUI mode, but it does
# not; we work around this when this script is invoked as "gvim" or "rgview"
# etc., but not when it is invoked as "vim -g".
if [ "$gui" ]; then
	# Note: this isn't perfect, because any error output goes to the
	# terminal instead of the console log.
	# But if you use open instead, you will need to fully qualify the
	# path names for any filenames you specify, which is hard.
	exec "$binary" -g $opts ${1:+"$@"}
else
	exec "$binary" $opts ${1:+"$@"}
fi

With this better command:

# Last step:  fire up vim.
# The program should fork by default when started in GUI mode, but it does
# not; we work around this when this script is invoked as "gvim" or "rgview"
# etc., but not when it is invoked as "vim -g".
if [ "$gui" ]; then
  # Note: this isn't perfect, because any error output goes to the
  # terminal instead of the console log.
  # But if you use open instead, you will need to fully qualify the
  # path names for any filenames you specify, which is hard.

  # Handle stdin
  if $stdin; then
    exec "$binary" -g $opts -
  elif $diffmode; then
    exec "$binary" -f -g -d $opts $*
  elif $tabs && [[ `$binary --serverlist` = "VIM" ]]; then
    #make macvim open stuff in the same window instead of new ones
    exec "$binary" -g $opts --remote-tab-silent ${1:+"$@"} & 
    wait
  else
    exec "$binary" -g $opts ${1:+"$@"}
  fi
else
  exec "$binary" $opts ${1:+"$@"}
fi

The first two branches are pretty clear – they just invoke the MacVim binary in the correct way, for our different modes. The third one uses the very awesome –remote-tab-silent option, which gives us the ability to reuse the same window with new tabs when we edit multiple files. Neato!

Finally, if you don’t want to do the modifications yourself, it’s available as a gist, so you can download it and use it as a drop-in replacement for the vanilla mvim script: https://gist.github.com/3780676

About the Author: Jake Alheid

Jake is a Python evangelist and is a developer at about.me in San Francisco. He is also the creator of pyconfig and a code contributor on github.