Excerpt from Linux Cookbook, Part 1
by Carla SchroderEditor'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.listCompile and install your new program, then generate the post-installation list:
# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-postinstall.listThen create a list of files installed by Joe by diffing the two lists:
$ diff joe-preinstall.list joe-postinstall.list > joe-installed.listDiscussion
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 1007or:
$ 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 
|
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-shUse 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_keyYou'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.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 14 of 14.
-
Mon Dieu! Where's Francois?!
2004-12-13 17:44:30 wmat [Reply | View]
What's with the title of this article?! Marcel Gagne has been writing Cooking With Linux for 6 years now for Linux Journal.
Bill
-
have you tried checkinstall?
2004-12-13 10:01:27 wjhenney [Reply | View]
Surely 4.3 would be better managed using checkinstall, which creates an RPM (or debian, or slackware package) and installs it for you. -
have you tried checkinstall?
2004-12-13 15:29:25 Carla Schroder [Reply | View]
This is a book excerpt- not the whole book! The book covers RPM, Yum, apt-get, dpkg, source installs, and CheckInstall. A link to the Table of contents is here.
-
what about opt?
2004-12-10 16:37:54 wizkid [Reply | View]
everything not handled by the package management is installed in /opt
i got along very well this way and as far as it occured to me, this is the place where it belongs. and then it might make sense to do the find-grep-install-find-grep-diff trick. at least more sense than scanning the whole filesystem which nowadays can be quite huge.
-
Some Corrections
2004-12-09 23:44:29 shlomif [Reply | View]
The -v option for grep does not "turn on verbosity". What it does is invert
the match and only display things that don't match. -e '^' does not mean
exclude the following directory. It specifies a pattern to match, that
happen to match at the beginning of the line (hence the "^"). Several -e's
specify several patterns.
In regards, to the solution proposed for 4.3, it is pretty brain-dead.
Scanning the entire file-system twice is going to take a long time if it is
very crowded. Furthermore, if something else is done there (like a cron-job
or a different user handling his files), it may have some false positives.
Generally, what I do to install programs, is either install from RPM (or
.DEB or whatever), or use autoconf's --prefix option to install everything
under its own directory.
"slay" is interesting.
"keychain" is also interesting.
-
Some Corrections
2006-05-27 07:09:30 robhogg [Reply | View]
What has not been commented on in the follow-ups to shlomif's post, is the (absoloutely correct) point that the explanations given for the flags used with grep are erroneous and misleading. This is especially serious in a book aimed at people who are not veryexperienced with Linux.
I am surprised not only that it slipped past the proofreaders but that O'Reilly have this on their website to promote the book. I had been thinking of getting it, but seeing such a sloppy error has made me reconsider.
-
Some Corrections
2005-01-13 10:52:46 SlowBurn [Reply | View]
Did you read the preface in the book. It isn't really meant for advanced users, but people new to the OS. While the methods describe are not the most optimal, they are easy to follow and understand.
I think that is the point of it really. Once the reader has built a base of understanding they can dig out the most optimal way to do something and comprehend what it is that they are doing and why. -
Some Corrections
2004-12-10 10:10:43 Fred_Arnold [Reply | View]
"Brain dead"? No it isn't. I use almost the same method for generating file lists for source installs, because many makefiles do not include an "uninstall" target, so it saves a lot of time when I want to remove a program. I also exclude mounted network shares. Sometimes I will install everything in a single directory using the --prefix option for ./configure, for an application that I know I'm probably going to test and remove, but that presents its own problems- like program documentation that assumes certain file locations, so you have to spend more time making sure config files and commands reflect the correct filepaths. And it puts files in illogical locations, instead of config files in /etc, logfiles in /var, and so forth.
Package installs really don't pertain to source installs. :) -
Some Corrections
2004-12-26 02:57:38 trb [Reply | View]
In most cases 'make install DESTDIR=/some/dir' is really the best way to do this. Once you make your list (find /some/dir | sed 's!^/some/dir!!' > file-list), you just 'make install' again and everything goes where it's really supposed to. No muss, no fuss.
In cases where that doesn't work I can think of all kinds of suboptimal-but-still-better ways to do it besides finding and grepping (twice!) the whole file system, including using a union mount to direct all the newly-installed files to a scratch filesystem or doing one build with './configure --prefix' set to a scratch directory to make your list and then building the package again without the (or with a different) --prefix option.
There are so many ways of doing this that are quicker, easier, and work better, that I think "brain dead" is a pretty good label in this case.
Ultimately, of course, if your OS uses package management, it's smarter to just build your own packages and let the helper scripts/apps worry about making a file list. Package management eases system maintenance and upgrading by a huge margin, especially when you have to manage multiple systems.
Plus in the case of distros like Gentoo and Red Hat (and just about everything else), where you have things like .spec and .ebuild files that script your build process, you're essentially documenting how to build the package while you're actually doing it, forcing you to take a step you should be taking anyway to make upgrading to future versions of the same software as painless as possible. -
Some Corrections
2004-12-11 17:51:15 oisinfeeley [Reply | View]
Package installs really don't pertain to source installs. :)
If the system that you're working on has package-management then it would be easier in the long run to use that system. It's possible to take source files and make your own debs or rpms. This make upgrading, removing etc _much_ easier.
It's definitely going to be quicker than doing a find, outputing a list, then diffing the list.
Brain-dead may be a harsh description, so let's call it "sub-optimal" instead.
I recently installed SuSe Linux 9.2 professional on a machine that I have previsouly installed other versions of Linux Mandrake 10, SuSE 8.X, etc. and everything worked ok before. now with SuSe9.2 the CD-ROM tray is always poping out for some unknown reason. Does anybody has any suggestion on how to fix this problem?
Help is appreciated, Thanks.