How to remove an imported gpg-key from RPM

Importing a gpg-key into the RPM database is simple but removing one not so much. Here are the steps to find the gpg-key you are looking for and remove it.

Step 1: find all imported gpg-keys and their owners

Open a terminal and issue the following command:

This will show you all the gpg-keys that were imported into the RPM database and who they belong to. For example, if you have a box with Fedora, the Google Chrome repo, the Adobe Flash repo, and the RPMfusion free/nonfree repo’s installed then you will see something like this:

Step 2 – delete the gpg-key

Delete the gpg-key with:

For example if you want to delete the gpg-key from the Adobe Flash repo then you would use the following command:


For a discussion about retaining or deleting old gpg-keys see this post on the fedora-devel mailinglist.

How to disable delta RPMs on Fedora 20

If you maintain a local mirror of Fedora or have fast WAN access to a Fedora mirror near you then it is quite inefficient to let yum download the delta RPMs and then take ages to rebuild them. It’s much faster to just download the full update RPMs instead. Here’s how you disable delta RPMs:

Open /etc/yum.conf and in the [main] section add deltarpm=0:

Note that this is a global setting. So none of your repositories will use delta RPMs anymore.

How to disable delta RPMS for individual repositories

If you want to disable delta RPMS for individual repositories then here’s a neat trick. In /etc/yum.repos.d/your.repo add the following setting:

From man yum.conf:

deltarpm_percentage When the relative size of delta vs pkg is larger than this, delta is not used. Default value is 75 (Deltas must be at least 25% smaller than the pkg). Use `0′ to turn off delta rpm processing. Local repositories (with file://baseurl) have delta rpms turned off by default.

Fixes for the OpenLDAP example config and deployment tips

If you want to setup an LDAP server with OpenLDAP and are new to LDAP then you may have gone through the Admin Guide and bumped into some mysterious errors trying to setup the example configs. Here are some notes how to make this configuration work followed by some tips at the end about deploying an OpenLDAP based directory.

The example config in the Admin Guide is located in chapter 5.3 when viewing the guide as a single HTML file on the OpenLDAP website (link above) or in the PDF version of the Admin Guide.

The relevant part of the example config in chapter 5.3 in the Admin Guide (page 38 in the PDF version) is:

When trying to add this config to your OpenLDAP server with slapadd then you will see the following errors:

5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax

5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax

/etc/openldap34/slapd.d: line 1: duplicate index definition for attr “uid”

The solution:
1) remove the quotes from olcSuffix (line 34)

should become

2) remove the quotes from olcRootDN (line 36)

should become

3) remove the double uid entry

should be removed in it’s entirety so remove that line

Working example configuration

Note 1: this example config follows the files and paths on RHEL 6.3 or CentOS 6.3. If you use another distribution then you will need to figure out what those files and paths are for your distro.

Note 2: the section # BDB definition for in the Admin Guide also has the problems as described above. The solution is exactly the same: remove the quotes from olcSuffix and olcRootDN and remove the olcDbIndex: uid pres,eq line.

Note 3: in the example config below the lines starting with “by…” are preceded by two (2) spaces! If you do not use 2 spaces then the config file is invalid and you will get errors. To illustrate, each dot is a space:

Extended example configuration

Here is an extended version of the example config above with the loading of modules and monitoring added.

Note 1: this extended configuration example assumes that your OpenLDAP server has been custom built with dynamic modules. So this configuration does not apply to the default openldap-servers-2.4.23 RPM that comes with RHEL6/CentOS6.

Some tips when deploying an OpenLDAP based directory

1) use the latest OpenLDAP release

The OpenLDAP 2.4.23 release that comes with RHEL6/CentOS6 is ancient and has bugs. It also has several patches which introduce GnuTLS support. From reading the various discussions about those patches the OpenLDAP developers do not seem to look favourably upon those patches. Currently it does not seem very likely that those GnuTLS patches will be applied upstream by the OpenLDAP developers. So Red Hat is on it’s own when it comes to those patches. It is recommended to use at least the latest stable release, currently 2.4.33.

2) use the MDB database

It’s faster than the BDB or HDB database (2 to 2.5x with olcDbEnvFlags: writemap and olcDbEnvFlags: nometasync) and does not have the problems which BDB and HDB suffer from. More information about MDB can be found at the OpenLDAP MDB site. The paper and LinuxCon slides are an interesting read.

If you want to use the MDB database then you will probably want to use the OpenLDAP RE24 branch from git upstream. AFAIK there is no readily available RPM but you can use either the Fedora 18/19 OpenLDAP SRPM, strip it and adjust it to build the RE24 branch or get the 2.4.33 EL6 SRPMs from the LDAP ToolBox project and adjust it to build the RE24 branch. <sales pitch>If you need a consultant to create those RPMs for RHEL/CentOS, I can help</salespitch>

3) consider delta-syncrepl

If you need replication then (if possible) consider delta-syncrepl for the simple reason that it has been recommended on the OpenLDAP mailinglist by core members over and over again. More information about delta-syncrepl can be found here in the Admin Guide.

Update 1 on March 24, 2013 – per Howard Chu’s comment the Extended Example Configuration has been corrected by putting the Module config before the Schema config. Thanks Howard!

Update 2 on March 24, 2013 – please read Howard Chu’s comment on tip #1 ‘use the latest OpenLDAP release. Howard is the lead developer of the OpenLDAP project so his view on GnuTLS/MozNSS is both relevant as well as leading.