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.

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:

http://wordpress.org/latest.zip

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
# http://commandlineidiot.com
# You may use, modify, and redistribute this script freely
# Released: April 2008
# =======================
echo 'WordPress server location, without trailing slash (ex. /var/www/mysite.com/blog)'
read WPLOC
WPNEW='/tmp'
cd $WPNEW
rm -rf $WPNEW/wordpress
rm -f latest.zip
wget http://wordpress.org/latest.zip
unzip -o latest.zip
rm wordpress.zip
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/
exit

You can download the script here:

WordPress Update Script 0.1

Share and enjoy!

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/churchhats.com/

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:

~/bin/sexrobot

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
sexrobot

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!

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.

updatedb

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.

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?

config:
/home/USERNAME/www-config/sites-available/DOMAIN.COM

website documents:
/home/USERNAME/DOMAINNAME.COM

index page:
/home/USERNAME/DOMAIN.COM/index.html

access log:
/home/USERNAME/logs/DOMAINNAME.COM/access.log

error log:
/home/USERNAME/logs/DOMAINNAME.COM/error.log

cgi-bin:
/home/USERNAME/DOMAIN.COM/cgi-bin

The Script

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

http://commandlineidiot.com/scripts/siteup.txt

To use it, do the following:

mkdir ~/bin
cd ~/bin
wget http://commandlineidiot.com/scripts/siteup.txt
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 LinuxCommands.org: Writing Shell Scripts

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

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!

It’s available through the repository on Debian Etch and Ubuntu

sudo apt-get install apt-show-versions
To see everything installed via apt, use the bare command
apt-show-versions
Or you can use it to check on a single package
apt-show-version nano

1. As a handy checklist for the person who is writing it. They’re using it instead of a pad of yellow legal paper to keep track of how they set things up. These tutorials tend to have almost no notation about what things actually do, they’re just a running list of commands
2. To demonstrate how remarkably clever the person is. These tutorials tend to veer off into lengthly political rants in the middle, all about how infantile and shortsighted the distro developers were when they decided to include XYZ in the canonical sources list, rather than forcing users to follow this 97 step process that is marginally more secure, so long as you don’t accidentally leave off the semicolon at the end of one of the commands.

Where are the tutorials for people like me? I’m not a mouth-breathing moron, just ignorant about linux. I don’t want a running list of things to copy and paste into the command line, I want to understand what I’m doing. And, I want to know when you’re presenting alternatives that are your own personal hobby-horse rather the standard method. Don’t tell me “this is the best way” and then point me in some obscure direction that’s going to cause a dozen headaches later on when I have to alter every other tutorial I try to follow.

On Tutorial to Rule Them

So, I hereby present to you my first tutorial. This tutorial will allow you to rescue all of the other bad tutorials and make them useful again. It only does one thing, and there are only two steps, but they work.

wtf is this?

So, you’re following a tutorial, and it tells you to apt-get a dozen packages, If you’re like me, this makes you very nervous. I want to actually know what these things do before I dump them onto my server. Let’s say one of the packages is “php5-dev”

Enter the following in the command line:
apt-cache show php5-dev

You’ve just told the apt package manager application to get you information about this package. It doesn’t install anything, just tells you what the package does, along with some nifty info about other packages it’s dependent on. In this case, it shows the following:

Package: php5-dev
Priority: optional
Section: devel
Installed-Size: 2680
Maintainer: Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>
Architecture: amd64
Source: php5
Version: 5.2.0-8+etch1
Depends: autoconf, automake1.4, libssl-dev, libtool, shtool, php5-common (>= 5.2.0-8+etch1)
Filename: pool/main/p/php5/php5-dev_5.2.0-8+etch1_amd64.deb
Size: 342036
… snip …
Description: Files for PHP5 module development
This package provides the files from the PHP5 source needed for compiling additional modules.
.
PHP5 is an HTML-embedded scripting language. Much of its syntax is borrowed from C, Java and Perl with a couple of unique PHP-specific features thrown in. The goal of the language is to allow web developers to write dynamically generated pages quickly.
Tag: devel::lang:php, role::devel-lib

Sweet! So now I know that it contains the tools to compile additional modules for PHP5. I’m now smarter!

bash it

If you are following a lot of tutorials, you’ll end up typing the words “apt-cache show” until you go blind, or develop ganglion cysts on your tendons. Let’s make the automatic computrix machine do it for is. Open your .bash_profile file with your favorite text editor. I like nano:
nano ~/.bash_profile
hit control+v until your cursor reaches the end of the file, then add the following line:
alias c="apt-cache show"
hit control+x, then enter, and you’re out of the text editor. We want to force bash to reload the profile, so type the following:
. ~/.bash_profile
To see if it worked, type this:
c php5-dev
It should bring you back exactly the same info you saw up above. Huzzah!

Now, no matter how shitty the tutorial is that you’re following, you can check out the packages and see what they do before you apt-get install scurvey-dev-core and it translates all of your config files into Cyrillic.