Category Archives: debian

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.

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.

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/newdomain.com” 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?

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.

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!

show version

Just ran across a very useful little utility called apt-show-versions. It shows you the version installed for each of the apps you have on your server, along with whether or not they are the latest version. Used in conjunction with the apt-cache show command, this makes for a handy little set of tools for working your way through tutorials.

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

apache2, php5, phpmyadmin

So, I solved at least one of my nagging headaches. I ran into a brick wall trying to get phpmyadmin up and running on ubuntu.

The Setup

Ubuntu 7.04, Apache2.2, MySQL, PHP5, running on a VPS from slicehost.com. All installed from apt-get, all working fine. Gave MySQL root user a password, the login to MySQL from the command line works just fine.

Installed phpmyadmin from apt-get, everything’s cool, it sets up the appropriate symbolic links so that www.MYURL.com/phpmyadmin points the browser to the phpmyadmin login page.

The Problem

I go to www.MYURL.com/phpmyadmin, and I get the login page. I enter the MySQL user root + password. Sometimes it logs in. Sometimes it bounces me back to the login with no warning. Sometimes it redirects me to the login page and says “root”@”localhost” not permitted [password=YES]. Sometimes it’s the same warning, but with [password=NO], even though I have entered a password.

Sometimes, if I click login 3 or 4 times after it keeps redirecting me, I actually get let in to phpmyadmin. As soon as I do anything requiring privileges (create new user, create new database), I get bounced back to the login page again.

Troubleshooting

Here’s what I tried to fix it

1) Tried all browsers at my disposal (OSX: Firefox, Opera, Safari, Camino; Windows: IE6, IE7). Same problem with all.

2) Assumed it was a cookie issue. Dumped all cache and cookies on my browser, reset safari, relaunched apache2, tried again. Same problem.

3) Same as step 2, but also did a shutdown -r of the entire server, just in case. Old habits die hard.

3) Sacrificed male goat by the light of a full moon. Sticky fingers, but still no persistent login.

Nothing worked.

The Solution

Turns out, in order to run phpmyadmin with php5 on a 64bit ubuntu machine, you need to have a little package installed called php5-mcrypt. It’s not listed in the dependencies, so if you just use apt-get, it gets left behind.

sudo apt-get install php5-mcrypt

the conclusion

aaaarrrrrgh.

Let the record show that it was at this precise moment in time that I switched from Ubuntu to Debian for my server needs. If I wanted to shed this much stomach bile on figuring out required dependencies, I would strap on a pocket-protector and go join the gentoo geeks. At least then I know it’s up to me.