start-stop-daemon on CentOS/RHEL

(Note that I’ve only ever done this on CentOS 6.2. It should work in a lot of other places too though, especially other RHEL based distros.)

I really wanted to use the Smokeping init script that comes with Ubuntu 10.04.* LTS  on a CentOS 6.2 box. One look at it, however, and you will very quickly realise that out-the-box that isn’t something which is likely to work, possibly for other reasons, but definitely because you don’t have “start-stop-daemon” on a CentOS box; not yet at least 🙂

This helpful post suggested that if you pull the dpkg source from one of the Debian mirrors then you could build it, albeit quite nastily, and end up with a successful build of start-stop-daemon. However, it doesn’t have to build so nastily. Newer versions of dpkg build cleanly, as I discovered and have detailed below. As root or using sudo, do the following:

cd /usr/local/src
wget -c "http://za.archive.ubuntu.com/ubuntu/pool/main/d/dpkg/dpkg_1.15.8.4ubuntu3.tar.bz2"
tar jfxvh dpkg_1.15.8.4ubuntu3.tar.bz2
rm dpkg_1.15.8.4ubuntu3.tar.bz2
cd dpkg-1.15.8.4ubuntu2/
./configure --without-install-info --without-update-alternatives --without-dselect
make && make install

Now if you type “which start-stop-daemon” you should discover that it’s built and installed into /usr/local/sbin, and works perfectly just like it’s supposed to. And with that hurdle out the way, I could now finish getting that Ubuntu init script working on CentOS. Happy time 🙂

The easiest way to fix apt missing key issues

Sorry, this is a bit lazy of me, but at the moment I can only con­firm that this works on Ubuntu 10.04.4 LTS. It might, how­ever, work on other ver­sions too, and maybe also with Debian of course.

If when you run an apt-get update you are being told some­thing like this right at the end:

W: GPG error: http://196.x.y.z lucid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2940ABA983EF826A

… then install “add-apt-key” on the box, and run it, adding the miss­ing key itself to the end of the com­mand, as shown below.

root@xyz-box-bry-01:~# apt-get install add-apt-key
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  add-apt-key
0 upgraded, 1 newly installed, 0 to remove and 5 not upgraded.
Need to get 5,314B of archives.
After this operation, 81.9kB of additional disk space will be used.
Get:1 http://196.x.y.z/ubuntu/ lucid/universe add-apt-key 1.0-0.5 [5,314B]
Fetched 5,314B in 0s (270kB/s)
Selecting previously deselected package add-apt-key.
(Reading database ... 88896 files and directories currently installed.)
Unpacking add-apt-key (from .../add-apt-key_1.0-0.5_all.deb) ...
Processing triggers for man-db ...
Setting up add-apt-key (1.0-0.5) ...
root@xyz-box-bry-01:~# add-apt-key 2940ABA983EF826A
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: requesting key 83EF826A from hkp server subkeys.pgp.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 83EF826A: public key "Opscode Packages " imported
gpg: Total number processed: 1
gpg:               imported: 1
OK
root@xyz-box-bry-01:~#

I’ve found that some­times the key server doesn’t have the key and so it’s not imported, but re-running the com­mand gen­er­ally fixes that as the next key server cho­sen usu­ally does end up hav­ing the key. Once you’ve suc­cess­fully imported the key, run “apt-get update” again and your prob­lem should no longer exist.

There was some­thing else I wanted to say but I’ve totally for­got­ten what it was.

Enjoy :)