Category Archives: tutorials

Jack That Shat!

So you just wooted some awesome new desktop speakers for your Ubuntu desktop computer, you plug them into the headphone jack, and you behold the megawatt goodness of thumping 4-inch speakers. But what ho? What’s this? The on-board sound card speaker is still pumping it’s pathetic little pings and bleeps into your otherwise blissful aural wonderland! It’s enough to drive a command line idiot to drink. Well, pretty much anything is enough to drive this command line idiot to drink. Things like “Mother’s Day” and “Tuesday”.

You would think that plugging something into the headphone jack would automatically shut off the speaker inside your box. You’d think that, but you’d be wrong. Not only are you wrong, but it’s such a stupid thing to want that the Ubuntu gods have hidden the setting under like 500 menu levels. Let’s go digging, shall we?

In the upper right corner, you have a volume icon. Click on that, and select “Volume Control”.

In the “Volume Control” dialog, you’ll see all of the volume sliders for various outputs. Select “Preferences”.

Now, you can control which settings show up in the “Volume Control” dialog. About halfway down the list, you’ll find the setting for “Headphone Jack Sense”. Yes, let’s please jack some sense into these headphone outputs, shall we? Check the box.

Now, back in the “Volume Control” dialog, you’ll find a new tab for switches. Our preference for headphone jack behavior shows up there.

That’s it! Now, you perfectly idiotic request to shut down the internal speakers when you plug in headphones (just like every other operating system does) will work with your fancy new speakers.

Now leave me alone. It’s 10am, and this tear-soaked gin & tonic isn’t going to guzzle itself.

Up the WP

Give me WordPress, give me WordPress
You can have all the rest, give me WordPress

I love Matt’s little blogging engine that could. It’s easy, fast, and pretty to look at. It’s easy to install. It is not, however, fun to upgrade.

That’s a problem, because people keep on coming up with tricksy little ways to burninate WordPress. Now, the folks who write the code are pretty good at staying on top of chinks in the armor, but that means that every time they say “update”, I have to update. Being the lazy ass that I am, I don’t like to keep doing things the hard way, ftp’ing data up and down, so I wrote a little bash script to do the badness for me. Now, I can go from vulnerable to updated in 0.4 seconds flat!

Let me take just a second to give mad props to the WordPress folks for a simple decision they made early on, that makes a world of difference to guys like me: you will always, always find the latest version of WordPress at the same location:

Simple, easy, but by avoiding all the complications of version numbering and folder locations in the download URL, they make it possible to write scripts like this. Thanks, guys!

If you don’t know how to use bash scripts, check out this tutorial: Bash it! Bop it! Script it!. It’ll show you where to put the script, how to make it executable, and how to call it from the command line. The script itself is in the download link below, and it’s pretty well documented, so you should be able to figure out why everything is there. Here’s a stripped down version, with none of the documentation:

#! /bin/bash
# =======================
# WordPress Upgrade Script 0.1
# Written by Command Line Idiot
# You may use, modify, and redistribute this script freely
# Released: April 2008
# =======================
echo 'WordPress server location, without trailing slash (ex. /var/www/'
read WPLOC
rm -rf $WPNEW/wordpress
rm -f
unzip -o
rm -rf $WPLOC.bak
cp -rv $WPLOC $WPLOC.bak
cp -rfv $WPNEW/wordpress/*.php $WPLOC/
cp -rfv $WPNEW/wordpress/wp-admin/* $WPLOC/wp-admin/
cp -rfv $WPNEW/wordpress/wp-includes/* $WPLOC/wp-includes/

You can download the script here:

WordPress Update Script 0.1

Share and enjoy!

Bash it! Bop it! Script it!

I would rather spend 3 hours writing a program to do a task than have to spend 3 minutes doing it myself more than once. Seriously. I’m that lazy. The only task I like to do over and over again is opening a Corona, taking a sip, filling it back up with tequila, and passing out in a pool of my own vomit. Or, as my kids like to call it, “Thursday.”

That kind of laziness means I use a lot of bash scripts to do regular tasks on my server. I have scripts to do automated backups, scripts to setup new virtual domains, scripts to prop up my fragile ego with repeated compliments, scripts to do just about every repeating task that goes into maintaining a barely functional webserver.

There are several tutorials out there for how to start writing scripts, but none of them have my flair for drunken bravado and outrageous sexual innuendo. So, I proudly present a very basic starter guide to writing a bash script:

How to Write A Bash Script

You know all those fancy commands you keep typing into the command line? Things like

cp -rv secretpr0nstash/*.avi /var/www/

Well, those same commands can be stored in a file, and can be executed whenever you need to, by invoking the name of the file. Let’s start with a very basic file. It just has 3 lines:

#! /bin/bash
# sexy robot script
echo "You are the sexiest robot"

The first line tells the system which shell to use when interpreting the commands that follow. The second line is a comment, to remind me in 6 months what the point of the script is. You can place these throughout the script to remind yourself why you did what you did when you wrote the thing. Finally, the third line is the actual command. It tells the system to output the given text back to the shell.

If you’re looking to learn more about how to write complex scripts, I highly recommend these two guides:
Advanced Bash-Scripting Guide
Writing Shell Scripts

So, now what?

Where to Put It

Now, you need a place to put the script. I keep all of mine in a folder called “bin” inside of my user folder. To create the folder, type:
mkdir ~/bin
cd ~/bin

now, invoke your favorite text editor to open a new file, and start entering in the code:

nano sexrobot

Enter your code, save, exit, and TADA! you have your very own script to prop up your fragile ego with repeated compliments.

How to Make Go Go

Except, it still won’t run. Try it – type “sexrobot” into your command line. What happened? It mocked you, didn’t it. It told you that your crazy dreams of a sexy robot compliment did not exist.

Before we can invoke the command, we have to make it executable.

chmod 755 sexrobot

Now, I can execute the code. Try it again, with the whole location:


Now that it works, we can do the final step – add a line to our .bash_profile file, so that every time we log in, the shell goes into our bin folder to look for commands.
nano ~/.bash_profile

Go to the end of the file, and add the following line:
export PATH="$PATH:~/bin"

Reload the bash_profile settings:
. ~/.bash_profile

If we did everything right, we should be able to execute our new script from any folder, just by typing the name of the file. Let’s try it:
cd /tmp

In Conclusions

Now that I don’t have to do all these repetitive server maintenance tasks, I can focus on more important things, like repetitive binge-drinking to drown my own sorrow.

Ha Ha! Alcoholism is funny!

Housekeeping, or, How To Obsessively Blow Up The Files Left Behind

I install, and then uninstall, lots of different software packages on Debian. I’m trying to learn how this thing works, so I’ll often install something, poke around, and then remove it. But, I get paranoid about the package manager leaving things behind on my system. Cron jobs, config files, libraries, all that jazz.

So, I do some housekeeping to make sure that everything, absolutely everything, gets blown up when I remove a piece of software. Is it necessary? Probably not. Does it satisfy my deeply rooted obsessive control issues? It does.

I’ll assume you’ve already removed the software using the package manager of your choice. For me, that’s aptitude. Throughout this little rundown, replace the word PACKAGE with the name of whatever you’re uninstalling.

sudo aptitude purge PACKAGE

Then, we need to hunt down and kill every remaining bread crumb that this thing left behind. We’ll be using the “locate” tool. It’s a fast search tool that refers to an existing database of files. Start by kicking into super user mode:

sudo su

Then, update the database that locate uses. This rebuilds an updated list of the files on your system.


Next, we want locate to find all of the files that were left behind.

locate PACKAGE

This will print them all to the screen. See them there, smiling back at you? You thought you were clean, you dirty bird, but there they all are. Filthy. Filthy files. Dirty. Dirty.

Well, looking at them on the screen isn’t all that useful for us. What we really need is some way to generate a list of these files that we can then process for deletion, one at a time. Go go command line, go!

locate PACKAGE > /tmp/PACKAGE_files.txt

head to your /tmp folder and take a look – there should be a .txt file there that lists each of the files left behind. Check it out:

cat /tmp/PACKAGE_files.txt

It should look identical to the output of the locate command we used earlier.

Now, we use a little Command Line MagicĀ©, and no, I’m not talking about cocaine. Sweet, sweet cocaine, gives us the go-go to make everything clean. Mmmm, clean. So clean.

We want a command that will pass each line of our new text file into the “rm” command, and give us the option to delete each one. Why, hello there xargs, so nice to see you.

cat /tmp/PACKAGE_files.txt | xargs -l1 -p rm -rf

What’s going on here? The “cat” command will output the content of our txt file. The pipe passes it along to the next command. “xargs” lets us input that data into a new command, in this case “rm”. The “-l1” switch on xargs (that’s the letter “L” and the number “one”) executes the command on one line at a time, instead of the whole batch. The “-p” switch will ask us for permission on each file, so that we have some control over what we want to delete. The “-rf” switch on the “rm” command will remove files recursively, and will force the issue if there are warnings or errors.

If we did everything right, it should start ripping through the files, asking you if you want to delete each one. Y for yes, N for no, and Tada! you have a system clean enough to avoid those awkward OCD freakouts at 2am.

If you want to double check the process, run the locate command again:

updatedb && locate PACKAGE

It should come back clean. Not dirty. Clean. Like pure white linen sheets on a bed of unicorn feathers. So clean. So nice and clean. And now, the sleeping.

Plate Up! Bash Script for Apache VHost Setup

In the sisyphian marathon of blowing up and rebuilding my server, I’ve had to go through the process of reconfiguring my virtual hosts for Apache2 several times. Well, that gets a bit tedious. How can my hands do the very important jobs of holding a beer up to my lips whilst scratching my man candy if they have to keep typing “sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/” over and over again?

bash it!

Fear not, my young linux adventurers. There IS a better way! Pop that cold beer, pull up some sweats, and feast your eyes on my hand dandy little bash script for automatically setting up yon website. Here’s what it does, in a nutshell:

  1. Asks for the new domain name
  2. Creates a new folder in the user folder with the domain name (/home/user/DOMAIN.COM)
  3. Creates a basic index.html file in the new domain folder that displays the name of the domain when accessed.
  4. Rolls 2d6 for Hacker Shield, to prevent magic-based attacks against your website. (planned for version 0.2)
  5. Generates a vanilla Apache vhost config file spelling out how Apache should handle requests for that domain.
  6. Generates an access log and an error log
  7. Generates a cgi-bin folder within the DOMAIN.COM folder

The script assumes you have Apache 2.2+ installed.

The non-compliance disclosure

Keep in mind that this script was written by me, for me, to help save me some effort. Because of that, it uses some non-standard locations for things. Why? Because I likes my shit where I likes my shit, that’s why!

I like having my apache vhost config files in my user folder, so that I don’t have to hassle with permissions. You can do the same thing with these two commands. First, make yourself a few new directories:

mkdir -p ~/www-config/sites-available
Then, link the apache site config folder to your new folder. Make sure this all goes on one line:

sudo ln -s /home/USERNAME/www-config/sites-available /etc/apache2/sites-available/

So where are things placed with this script?


website documents:

index page:

access log:

error log:


The Script

Here ’tis. Click here to view or download a .txt file with the script.

To use it, do the following:

mkdir ~/bin
cd ~/bin
mv siteup.txt siteup
chmod 755 siteup

Now, to invoke the script, type the following:
. ~/bin/siteup

If you want to find out more about bash scripts, including how to handle permissions and setting paths so that your scripts can be called by name, I highly recommend the following tutorial by William Shotts Jr. at Writing Shell Scripts

Questions? Comments? Feck Off! I’m too busy drinking this cold beer and fiddling my diddly.

postfix, dovecot, emailtastic!

I’ve gots the email! I gots the email!

Christopher Haas has written what might be the best tutorial I’ve ever run across for linux. It’s accurate, complete, breaks things down into manageable steps, and explains what you’re doing while you do it. It also contains several “check” steps, where it shows you how to check your system logs to see if the previous steps went as planned.

This is what a tutorial should be!

Howto: ISP-style Email Server with Debian-Etch and Postfix 2.3

If you’re trying to get email up and running on your debian VPS, this is the place to start. It shows how to use postfix and dovecot, with secure login, spam and virus checkers. Everything you need for POP or IMAP.

Take note of the warning up front about the proper naming scheme for your host. Almost every VPS image that I’ve run across uses a default naming in /etc/hosts and /etc/hostname that is incorrect for proper configuration of postfix (or even apache!). This article explains why and what to do about it:

Naming Issues with Linux and xBSD

Happy installing of email!