if you’re running Debian, the random numbers used to generate your SSH keys may not have been, how you say … random. Turns out they’re predictable! Check this out, and digg it up, let the peoples know the truth!
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:
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.
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:
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.
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?
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:
- Asks for the new domain name
- Creates a new folder in the user folder with the domain name (/home/user/DOMAIN.COM)
- Creates a basic index.html file in the new domain folder that displays the name of the domain when accessed.
- Rolls 2d6 for Hacker Shield, to prevent magic-based attacks against your website. (planned for version 0.2)
- Generates a vanilla Apache vhost config file spelling out how Apache should handle requests for that domain.
- Generates an access log and an error log
- 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?
Here ’tis. Click here to view or download a .txt file with the script.
To use it, do the following:
mv siteup.txt siteup
chmod 755 siteup
Now, to invoke the script, type the following:
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.
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!
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:
Happy installing of email!
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
Or you can use it to check on a single package
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.
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.
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.
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.
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
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.