Wednesday, December 30, 2009

local usefull databases

By default, linux and unix systems have two usefull databases installed. Those databases may speed up your work as a system administrator.

First of all, there is the locate database. This database contains the list of the files in your system. Imagine you need to edit a file whose name is "password" but you can't remember its path. A quick way to do it would be :
luangsay@ramiro:/tmp$ locate -r password$
(-r switch is for using regular expressions).
To initialize the database or update it, you can use the command updatedb. Normally, your operating system does it with a cron task.

The second database is apropos, a french word which means "about". This is a collection of the first description sentences (the whatis sentence) of all the man pages. To know all the manpages that deal with the configuration of passwords, you would type :
luangsay@ramiro:/tmp$ apropos -s 5 password
login.defs (5) - configuration de la suite des mots de passe cach├ęs shadow password
passwd (5) - the password file
shadow (5) - encrypted password file
smbpasswd (5) - The Samba encrypted password file
Here, to create/update the database, you will use makewhatis (or mandb in Debian).

Another interesting database that is less known is perlindex. Quite usefull because perl is (still...) used by many system admins. This tool indexes all your perl modules documentation pages. So, to find all the modules installed on your system that deal with LDAP, you can type:
luangsay@ramiro:/tmp$ perlindex ldap
1 1.791 share/perl5/URI/
2 0.317 share/perl5/
3 0.137 share/perl/5.10.0/pod/perlhpux.pod
Highest mark (1.791) gives you the most relevant page. If you pulse 1, you'll get the perldoc page printed. Of course, such database isn't as big as the CPAN one, but it proved to have helped me quite a few times in the past.

Finally, I would like to say a word about maybe my prefered database. I mean, the debian packages database. Debian apt-get system is a lot more faster than redhat yum software and it offers you many more packages. I believe every debian admin knows the power of the "apt-cache search/show" commands so I won't waste my time giving an example. For those who don't have a debian based distribution, you can get an idea of this database on this web page. If you have to install a new solution on your servers, and you don't know what software can handle it, the debian package can give you a precious help to get the information. Even if you don't have debian, it can be very usefull.

Wednesday, December 2, 2009


The first thing I was taught on my first day as a system administrator was to always do a backup of the files I wanted to modify. The way I was told was this one :
cp foo foo.20091202
(the extension is year - month - day)

This proved to be a poor way to backup files and it has a lot of drawbacks. Now, I usually use RCS to do this job. It gives you most of the advantages of a revision control system like CVS or subversion but without the burden to install lot of binaries, libraries and create global repositories (of course, with rcs you don't have the concurrent access feature nor authentication stuff but we don't really care about that just to backup some configuration files).

In Debian, you can install it like this :
apt-get install rcs
If you have Redhat, it would be :
yum install rcs

Then, to backup a file in the current directory :
mkdir RCS
ci -l foo
("-l" option is for the lock feature of rcs, something that does not seem very usefull to my view).

After some changes in the file, you can see them with rcsdiff :
rcsdiff foo
To save a new version of the file :
ci -l foo
If you want to list all the versions of your file :
rlog foo
To check the differences between version 3 and version 5 :
rcsdiff -r3 -r5 foo
And finally, if you want to get version 4 back :
co -r4 foo

One thing I do appreciate by using rcs to modify every configuration file, is that it is very easy to know all the changes you've made on your server (for instance, if you have to migrate the server to a new OS it may be helpfull) by typing :
locate RCS

Of course, this will never sustitute a real remote backup policy (with TSM or Netbackup for instance) of your server. But it is much more flexible to know what was changed in a file with RCS than looking your modified versions on the tapes...

Keep in mind that RCS is for local changes. If you want to do the same modification on a file on all your servers, maybe you should pass to a CVS/subversion system, or use a different method to centralize your changes.