FSVS: Install on CentOS 5.4

(Also see my older post on this: FSVS - Install on CentOS 5. Or the original post where I explained the power of FSVS for sysadmins.)

I'm going to start with the assumption that this is a base CentOS 5.4 install without *any* package groups selected during the initial install. In my case, this is a DomU that I'm setting up under Xen to serve as testing server for web development. The only thing I've done so far is setting the root password and configuring it to use a static IP address.

The basic steps will be:

1. Setup the RPMForge repository
2. Install the packages needed for FSVS
3. Download and compile FSVS
4. Configure ignore patterns
5. Do the base check-ins

Setting up RPMForge

In order to get the latest Subversion packages for your system, you'll have to add RPMForge as a source repository. The CentOS base repository only has Subversion 1.4.2 and the latest is currently 1.6.6. I recommend doing this in conjunction with the yum-priorities package.

# yum install yum-priorities

After installing the yum-priorities package, you should edit the CentOS-Base.repo file found under /etc/yum.repos.d/. For the base repositories, I recommend setting them to priority values of 1 through 3. For example:

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
priority=1
exclude=subversion-*

I generally give the [base], [updates], [addons], [extras] repositories a priority of "1", with [centosplus] and [contrib] getting a priority of "3". In addition, you'll need to add or edit the "exclude=" line in the [base] repository section to exclude Subversion from being sourced from that repository. This will allow the Yum package manager to look in other repositories to find Subversion. Now we can install the RPMForge repository (see Using RPMForge).

# cd /root/
# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
# rpm -Uhv rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
# cd /etc/yum.repos.d/

Now you should edit the rpmforge.repo file and insert a priority= line. I recommend a value of 10 or 25. You can now verify that you'll pull in the latest Subversion package by the following command:

# yum info subversion
Available Packages
Name : subversion
Arch : x86_64
Version : 1.6.6
Release : 0.1.el5.rf
Size : 6.8 M
Repo : rpmforge

Install the packages needed for FSVS

# yum install subversion subversion-devel ctags apr apr-devel gcc gdbm gdbm-devel pcre pcre-devel apr-util-devel

Download and compile FSVS

As always, you shouldn't compile code as the root user.

# su username
$ mkdir ~/fsvs
$ cd ~/fsvs
$ wget http://download.fsvs-software.org/fsvs-1.2.1.tar.bz2
$ tar xjf fsvs-1.2.1.tar.bz2
$ cd fsvs-1.2.1
$ ./configure
$ make
$ exit
# cp /home/username/fsvs/fsvs-1.2.1/src/fsvs /usr/local/bin/
# chmod 755 /usr/local/bin/fsvs

Creating the repository on the SVN server

This is how we setup users on our SVN server. Machine accounts are prefixed as "sys-" in front of the machine name. The SVN repository name matches the name of the machine. In general, only the machine account should have write access to the repository, although you may wish to add other users to the group so that they can gain read-only access.

# useradd -m sys-www-test
# passwd sys-www-test
# svnadmin create /var/svn/sys-www-test
# chmod -R 750 sys-www-test
# chmod -R g+s sys-www-test/db
# chown -R sys-www-test:sys-www-test sys-www-test

Back on the source machine (our test machine), we'll need to create an SSH key that can be used on our SVN server. You may wish to use a slightly larger RSA key (3200 bits or 4096 bits) if you're working on an extra sensitive server. But a key size of 2048 bits should be secure for another decade for this purpose.

# cd /root/
# mkdir .ssh
# chmod .ssh 700
# cd .ssh
# /usr/bin/ssh-keygen -N '' -C 'svn key for root@hostname' -t rsa -b 2048 -f root@hostname
# cat root@hostname.pub

Copy this key into the clipboard or send it to the SVN server or the SVN server administrator. Then we'll need to create a ~/.ssh/config file to tell the user what account name, port and key file to use when talking to the SVN server.

# vi /root/.ssh/config
Host svn.tgharold.com
Port 22
User sys-www-test
IdentityFile /root/.ssh/root@hostname

Back on the SVN server, you'll need to finish configuration of the user that will add files to the SVN repository.

# su username
$ cd ~/
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ cat >> authorized_keys
(paste in the SSH key from the other server)
$ chmod 600 authorized_keys

Now you'll want to prepend the following in front of the key line in the authorized_keys file.

command="/usr/bin/svnserve -t -r /var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding

That ensures (mostly) that the key can only be used to run the svnserve command and that it can't be used to access a command shell on the SVN server. Test the configuration back on the original server by issuing the "svn info" command. Alternately, you can try to ssh to the SVN repository server. Errors will usually either be logged in /var/log/secure on the source server or in the same log file on the SVN repository server. Here's an example of a successful connection:

# ssh svn.tgharold.com
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) )

This shows that they key is running the "svnserve" command automatically.

Connect the system to the SVN repository

The very first command that you'll need to issue for FSVS is the "urls" (or "initialize") command. This tells FSVS what repository will be used to store the files.

# cd /
# mkdir /var/spool/fsvs
# mkdir /etc/fsvs/
# fsvs urls svn+ssh://svn.tgharold.com/sys-www-test/

You may see the following error, which means you need to create the /var/spool/fsvs folder, then reissue the fsvs urls command.

stat() of waa-path "/var/spool/fsvs/" failed. Does your local WAA storage area exist?

The following error means that you forgot to create the /etc/fsvs/ folder.

Cannot write to the FSVS_CONF path "/etc/fsvs/".

Configure ignore patterns and doing the base check-in

When constructing ignore patterns, generally work on adding a few directories at a time to the SVN repository. Everyone has different directories that they won't want to version, so you'll need to tailor the following to match your configuration. However, I generally recommend starting with the following:

# cd /
# fsvs ignore group:ignore,./dev
# fsvs ignore group:ignore,./etc/fsvs/
# fsvs ignore group:ignore,./etc/gconf/
# fsvs ignore group:ignore,./etc/gdm/
# fsvs ignore group:ignore,./home/
# fsvs ignore group:ignore,./lost+found
# fsvs ignore group:ignore,./media/
# fsvs ignore group:ignore,./mnt/
# fsvs ignore group:ignore,./proc
# fsvs ignore group:ignore,./root/.gconf
# fsvs ignore group:ignore,./root/.nautilus
# fsvs ignore group:ignore,./selinux/
# fsvs ignore group:ignore,./srv
# fsvs ignore group:ignore,./sys
# fsvs ignore group:ignore,./tmp/
# fsvs ignore group:ignore,./usr/tmp/
# fsvs ignore group:ignore,./var/gdm/
# fsvs ignore group:ignore,./var/lib/mlocate/
# fsvs ignore group:ignore,./var/lock/
# fsvs ignore group:ignore,./var/log/
# fsvs ignore group:ignore,./var/mail/
# fsvs ignore group:ignore,./var/run/
# fsvs ignore group:ignore,./var/spool/
# fsvs ignore group:ignore,./var/tmp/

Then you'll either want to ignore (or encrypt) the SSH key files.

# cd /
# fsvs ignore group:ignore,./root/.ssh
# fsvs ignore group:ignore,./etc/ssh/shadow*
# fsvs ignore group:ignore,./etc/ssh/ssh_host_key
# fsvs ignore group:ignore,./etc/ssh/ssh_host_dsa_key
# fsvs ignore group:ignore,./etc/ssh/ssh_host_rsa_key

You can check what FSVS is going to version by using the "fsvs status pathname" command (such as "fsvs status /etc"). Once you are happy with the selection in a particular path, you can do the following command:

# fsvs ci -m "base check-in" /etc

Repeat this for the various top level trees until you have checked everything in. Then you should do one last check-in at the root level that catches anything you might have missed.

FSVS ignore patterns (1.2.0)

Here's an example of a more complex FSVS ignore/take pattern.

On our mail server, we store all mail in MailDir folders under the structure of:

/var/vmail/domainname/username/

We keep our user-specific Sieve scripts in a "Home" folder under that location.

/var/vmail/domainname/username/Home/

So obviously, we want to version the Home folder under each user. But we don't want to version the other MailDir folders at all. The trick to this is that because our folder structure is predictable, we can do it in a handful of FSVS ignore patterns.

# cd /
# fsvs ignore dump >> /root/fsvs-ignore-yyyymmdd.txt

That makes a backup of your current rules, just in case you decide that you don't like your changes (they can be reloaded with "fsvs ignore load < filename").

# cd /
# fsvs ignore group:ignore,./var/vmail/lost+found
# fsvs ignore group:take,./var/vmail/*
# fsvs ignore group:take,./var/vmail/*/*
# fsvs ignore group:take,./var/vmail/*/*/Home
# fsvs ignore group:take,./var/vmail/*/*/Home/**
# fsvs ignore group:ignore,./var/vmail/**

Line 1 "group:ignore,./var/vmail/lost+found": In our setup /var/vmail is a separate mount point, so we'll want to ignore the lost+found folder.

Line 2 "group:take,./var/vmail/*": This tells FSVS to version anything at or below /var/vmail.

Line 3 "ignore group:take,./var/vmail/*/*": Grabs the next directory level and files below /var/vmail.

Line 4 "group:take,./var/vmail/*/*/Home": Now we grab just the "Home" folder inside of the user's MailDir directory. This lets us ignore the new|cur|tmp folders as well as the other hidden MailDir folders (such as .Junk).

Line 5 "group:take,./var/vmail/*/*/Home/**": Grab everything inside of Home and below that point. This will grab all of the Sieve scripts or other files that are located there. If you wanted to exclude certain files in Home, you would insert that ignore rule above this line.

Line 6 "group:ignore,./var/vmail/**": This is the clean-up rule. Anything not explicitly mentioned above here will now be ignored. This keeps us from versioning the messages inside the user's MailDir folders.

Getting started with GPG4Win

GNU Privacy Guard for Windows Home Page (GPG4Win) - The GPG4Win project recently released version 2.0.1 of their product, so I figured it was a good time to reexamine GPG4Win. There have been a few changes since version 1, most notable for me is that WinPT is no longer part of the GPG4Win distribution.

Installation

For getting started, I strongly recommend using the gpg4win-light package at first as you probably won't need Kleopatra or the german-only manuals). As for the optional modules, I'd recommend installing GPA and GPGEx at a minimum. Note that GPGOL is still only compatible with Outlook 2003 and Outlook 2007, so you may wish to not install that module if you use other versions of Microsoft Outlook. In addition, you probably won't need Claws Mail at first.

By default, GPG4Win puts your key files under (or wherever your HOMEPATH environment variable points to?):

C:\Documents and Settings\USERNAME\Application Data\gnupg

Make sure you include this location in any backup programs that you are using. Your public and secret keyrings are stored in this folder and need to be backed up regularly.

Public Key Pairs

Now we get into the theoretical realm, GPG now supports RSA signing and encryption keys (in addition to the older DSA for signing and Elgamal for encryption methods). DSA signing keys are limited to 1024 bit lengths, while RSA signing keys can be much longer (512 to 4096 bits are commonly used). The only restriction that you should keep in mind for RSA keys is that you should never sign with the same key that you use for encryption (and vice-versa). In GnuPG v2, the default is now to create (2) RSA keys for the account, one for encryption and one for signing.

Typically, you'll want signing keys to have a very long lifespan (at least 5 years, maybe as long as 20 or more). This allows you to build a much larger web of trust before your key can no longer be used to sign other keys. However, you should really expire your encryption key after a few years. Then, a bit before your encryption key expires, you should add a new encryption subkey to your key with a new expiration date.

Unfortunately, the default creation options in GnuPG will assign the same expiration to both the signing key and the encryption keys. But this can be fixed using the "gpg --edit-key" command.

Creating a GPG key

gpg --gen-key
gpg (GnuPG) 2.0.12; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?

Unless you have a strong reason to use DSA/Elgamal, you may as well use the defaults in GPG v2 and pick "RSA and RSA".

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

If you're creating a key that will expire in the next 5 years, I recommend 2048 bits. For longer durations, you may wish to use 3172 or 4096 bits.

Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)

For an initial key where you're not protecting anything super critical, I suggest starting with a 25 year (entered as "25y") expiration date. You will be asked to confirm the expiration date (enter "y" to continue).

GnuPG needs to construct a user ID to identify your key.

Real name:

For personal use, I suggest just entering your name (i.e. "Thomas Harold"). But if you're creating a key for corporate/business use, I suggest adding a bit more information in this field to make things easier for others if they have more then one key with similar names. I recommend against using parenthesis in this field as it can be confusing later on. Square brackets "[]", curly braces "{}", or angle brackets "<>" are all good choices to set elements off from each other. Some examples:

Thomas Harold, Acme Inc.
Thomas Harold [Acme]
Thomas Harold
Thomas Harold {Example LTD}

Remember, that this and the next two fields are all public information that will be visible to everyone who uses your public key to send you things, or who uses your signing key to verify a signature.

EMail address:

This is very simple, you should enter the primary email address that you want associated with this key (i.e. "tgh@tgharold.com"). If you need to add additional email addresses, you can do that later using the "gpg --edit-key" command.

Comment:

The comment field is a public field and will be seen by others. I recommend putting website information here, or the full company name, or a combination of the two. Keep in mind that the contents of this field are typically displayed as enclosed in parenthesis, so avoid using parenthesis or brackets/braces here. Some examples:

www.tgharold.com
Acme Corporation - www.acme.corp
Example LTD, www.example.com

You selected this USER-ID:
"Thomas Harold [Acme] (Acme Corporate Sales - www.acme.corp) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

After entering those three values, you will be presented with how it might look to another user. As you can see, the comment gets wrapped in parenthesis while the email address gets presented inside of angled brackets. Once you are satisfied with how it looks, enter "O" for "Okay" to continue.

GnuPG will then pop-up a window that prompts you for a passphrase. This is extremely important. The passphrase that protects your key from unauthorized use is the weakest link of the entire GnuPG encryption chain. Pick something lengthy, yet easy to type, that is extremely difficult for someone to guess or attack. Write it down if you want, but keep that slip of paper secure in a safe or safety deposit box.

You will eventually be presented with something that looks like:

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2009-12-16
pub 3200R/AAFA2876 2009-11-21 [expires: 2009-12-16]
Key fingerprint = 0324 917E C27D 2FB0 DDEF ABFA 4DEE 71F0 AAFA 2876
uid Thomas Harold [Acme] (Acme Corporate Sales - www.acme.corp)
sub 3200R/1972B360 2009-11-21 [expires: 2009-12-16]

This means that GnuPG has finished generating your key and has saved it to your keyring. This sample key (both the encryption key and the signing key) will expire Dec 16, 2009.

The key fingerprint is an important piece of information that should be given to your contacts over a secure channel. It will allow them to verify that they have the correct key and that they are not subject to a man-in-the-middle (MitM) attack when they use the key. You can find out the fingerprints of keys in your keyring using the "gpg --fingerprint" command. Typically, you would send them your public encryption key via email or some other digital method while telling them the key's fingerprint over an entirely different medium such as a telephone call or a physical piece of paper (letter / package).

Editing your key

In order to edit your key using GnuPG, you must know the 8-digit key ID. In the above example it is listed on the line that starts with "pub". For example, the key that I just created has a key ID of "AAFA2876":

pub 3200R/AAFA2876 2009-11-21 [expires: 2009-12-16]

In order to edit the key, you will use the following command:

gpg --edit-key aaFa2876

As you can see, the key ID is not case sensitive as it is merely an 8-digit hexadecimal string.

gpg (GnuPG) 2.0.12; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub 3200R/AAFA2876 created: 2009-11-21 expires: 2009-12-16 usage: SC
trust: ultimate validity: ultimate
sub 3200R/1972B360 created: 2009-11-21 expires: 2009-12-16 usage: E
[ultimate] (1). Thomas Harold [Acme] (Acme Corporate Sales - www.acme.corp)

Command>

This shows us a bunch of information. The line that starts with "pub" gives us the following information:

pub - indicates that this is the primary key (you will also see "sub"
3200R - this is a 3200 bit RSA key (R=RSA, D=DSA, g=Elgamal)
AAFA2876 - the key ID (or subkey ID)
created: / expire(d|s): - the creation and expiration dates
usage: - indicates how the key can be used (S=sign, E=encrypt)

Useful commands at this point are:

fpr - show key fingerprint
list - list key and user IDs
quit - exit without making changes

Changing the expiration date

By default, all operations will occur to the primary key (the "pub" line) in this keyset. So before you edit a subkey, you need to tell GnuPG to work with that key. These keys are simply numbered 1-N as they are shown in the list.

Command> key 1

pub 3200R/AAFA2876 created: 2009-11-21 expires: 2009-12-16 usage: SC
trust: ultimate validity: ultimate
sub* 3200R/1972B360 created: 2009-11-21 expires: 2009-12-16 usage: E

This puts an asterisk by the "sub*" line telling us that we're going to work on the subkey with ID "1972B360".

Command> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 6m
Key expires at 05/19/10 20:28:31 Eastern Daylight Time
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "Thomas Harold [Acme] (Acme Corporate Sales - www.acme.corp) "
3200-bit RSA key, ID AAFA2876, created 2009-11-21

pub 3200R/AAFA2876 created: 2009-11-21 expires: 2009-12-16 usage: SC
trust: ultimate validity: ultimate
sub* 3200R/1972B360 created: 2009-11-21 expires: 2010-05-20 usage: E

As you can see, the subkey's expiration date changed from "2009-12-16" to "2010-05-20". If we had wanted to change the primary key's expiration date, we would've entered "key 0" then "expire" at the "Command>" prompt.

Once you are happy with the new expiration dates, enter "save" to save and quit the key editor.

Adding another User ID to the key

Let's say that you want to add a second email address to your key pairs. As before, you're going to use the "gpg --edit-key" command to do this.

gpg --edit-key AaFa2876

Then you'll issue the "adduid" command.

Command> adduid
Real name: Thomas Harold [Example]
Email address: tgh@example.com
Comment: www.example.com
You selected this USER-ID:
"Thomas Harold [Example] (www.example.com) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

Your key will now look like:

pub 3200R/AAFA2876 created: 2009-11-21 expires: 2012-11-20 usage: SC
trust: ultimate validity: ultimate
sub 3200R/1972B360 created: 2009-11-21 expires: 2010-05-20 usage: E
[ultimate] (1) Thomas Harold [Acme] (Acme Corporate Sales - www.acme.corp)
[ unknown] (2). Thomas Harold [Example] (www.example.com)

Now that we have two User IDs associated with this key, we should flag one of them as the primary.

Command> uid 2
Command> primary
Command> uid 0

pub 3200R/AAFA2876 created: 2009-11-21 expires: 2012-11-20 usage: SC
trust: ultimate validity: ultimate
sub 3200R/1972B360 created: 2009-11-21 expires: 2010-05-20 usage: E
[ultimate] (1) Thomas Harold [Example] (www.example.com)
[ultimate] (2). Thomas Harold [Acme] (Acme Corporate Sales - www.acme.corp)

The asterisk by the number in parenthesis is the currently selected user ID. If you see a dot/period after the number in parenthesis, that indicates which user ID is the primary.

Backing up your key

The following command allows you to export your secret key to an ASCII armored text file.

gpg -a --export-secret-keys aafa2876 >> my-secret-key.asc

You should also export your currently usable public encryption key.

gpg -a --export aafa2876 >> my-public-key.asc

You should print these files out as well as keeping an electronic copy in a secure location such as a safe or safe-deposit box. Don't leave the secret key ASCII file laying around. A sealed security envelope with a phrase and the current date written across the sealed flap and then covered with transparent tape is a good countermeasure to detect tampering.

CentOS 5, ClamAV 0.95 and /etc/sysconfig/clamav

Trying to configure the new ClamAV 0.95 as a milter for our Postfix install this week. So I've been doing some digging into the configuration files. Here's what I've found so far.

In order to get the newer ClamAV for Red Hat Enterprise Linux 5 (RHEL5) and CentOS 5, I had to use the RPMForge repository in order to get the 0.95 version.

The old clamav-milter package is outdated and should not be installed (use the newer clamav 0.95 or later package).

The /etc/rc.d/init.d/clamav script is still from 2008 and is very old. It references /etc/sysconfig/clamav which has an outdated setting called "CLAMAV_MILTER=yes". In ClamAV 0.95+, the milter was rewritten and now uses a configuration file (/etc/clamav-milter.conf) instead of command-line arguments. The init.d script that manages the clamd daemon is still for the older milter. It works fine for starting and stopping clamd, but you should not use the "CLAMAV_MILTER=yes" setting in the sysconfig file.

If you were using the /etc/sysconfig/clamav file to turn on the milter in RHEL5, then you will probably see the following error when you upgrade to ClamAV 0.95 or later:

Starting clamav-milter: clamav-milter: unrecognized option `--max-children=10'
ERROR: Unknown option passed
ERROR: Can't parse command line options

You'll need to convert your old command line options into configuration file options.