Excerpt from Linux Cookbook, Part 1

Editor's note: Carla Schroder, author of Linux Cookbook, has three tasty recipes to share in this week's excerpt. Whether you want tips on installing a program for easy uninstall, killing user processes, or better logins without passwords, Carla poses the problems and offers solutions. Too bad not all recipes can be this clear, quick, and painless. Join us again in a couple of weeks when Carla shares tips on running different window managers simultaneously with Xnest and hosting multiple domains with Apache.

4.3 Generating a List of Files from a Source Install for Easy Uninstalls

Problem

You need to know what files are installed on your system when you install a program from source code, so that you can find and remove all of them if you decide you don't want them anymore. Some program authors thoughtfully include a "make uninstall" target to perform a clean uninstall, but many do not.

Solution

You can use standard Linux utilities to generate a pre-installation list of all files on your system. Then generate a post-installation list, and diff the two lists to make a list of newly-installed files. This example uses JOE: Joe's Own Editor:

# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-preinstall.list

Compile and install your new program, then generate the post-installation list:

# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-postinstall.list

Then create a list of files installed by Joe by diffing the two lists:

$ diff joe-preinstall.list joe-postinstall.list > joe-installed.list

Discussion

Using find and grep together makes it easy to exclude directories that don't matter for your final list. The -v option for grep turns on verbosity. -e ^ means "exclude the following directory."

You don't need to bother with /proc or /tmp files, because these are transient and constantly changing. /dev files are managed by the system, so you can ignore these as well. And it's a also an important safety measure—when you remove a program manually, using your nice diff list, /proc, /tmp, and /dev are all directories you shouldn't touch in any case.

See Also

• grep(1), find(1), diff(1)

8.8 Killing User Processes the Easy, Fun Way

Problem

You need to delete a user, but userdel reports that some ofthe user's processes are running. You sure would like single command to find and stop all of the user's processes.

Solution

Use the slay program:

# slay foober
slay: -KILL is kicking foober's butt!
slay: Whoa, I have the power supreme.

slay finds and kills all the user's processes at once, saving you the trouble of hunting them down and killing them yourself. slay has four modes: nice, normal, mean, and butthead. Mean mode kills any nonprivileged user who attempts to slay another user. Set your desired mode in /etc/slay_mode.

Discussion

The traditional method of finding processes belonging to a user is to use ps, as in:

$ ps U 1007

or:

$ ps U foober
3936 ? S 0:00 xchat
3987 ? S 0:00 /usr/lib/galeon-bin
4209 ? S 0:00 kdeinit: kio_file file /tmp/ksocket-carla/
klauncherkF21rc.slave-

You can then kill one by one:

# kill 3936
# kill 3987
# kill 4209

Related Reading Linux Cookbook By Carla Schroder

See Also

• slay(1), kill(1)

17.7 Better Passwordless Logins with keychain

Problem

ssh-agent is nice, but you still have to enter a passphrase with every new shell you open, and when you log out you have to start over. Also, ssh-agent doesn't enable passphraseless SSH transfers to work with cron.

Solution

First, set up your system to use ssh-agent. Then use keychain to keep your SSH passphrases alive, system-wide, until you reboot. keychain also makes it possible to run SSH transfers from cron.

Download and install keychain from the usual sources; it comes in RPMs, .debs, and sources. Then edit your local ~/.bash_profile, adding these lines:

keychain id_dsa
. ~/.keychain/$HOSTNAME-sh

Use the real name of your private key: id_rsa, my_own_groovy_key, whatever. Be sure to use the leading dot on the second line; this tells Bash to read the file named on the line.

That's all you have to do. Now when you log in to your local workstation, a keychain prompt will appear, asking for the passphrase of your key. keychain will handle authentications until the system reboots.

Discussion

You can name as many keys as you wish to use, like this:

keychain id_dsa apache_key ftp_key

You'll enter the passphrase for each one at system login. Then keychain will handle authentications as long as the system stays up, even if you log out and log back in a few times. When you restart the system, you start over.

A lot of documentation tells you to use null passphrases on keys generated for servers, to enable unattended reboots. The risk is that anyone who gets a copy of the private key will be able to easily misuse it. As always, you'll have to decide for yourself what balance of convenience and security is going to serve your needs.

See Also

• ssh(1), ssh-add(1), ssh-agent(1), keychain(1)
• SSH, The Secure Shell: The Definitive Guide

Carla Schroder is a self-taught Linux and Windows sysadmin and the author of the Linux Cookbook.

Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.