Reviving dead Centos 4 repos

Edit
/etc/yum.repos.d/CentOS-Base.repo

Comment out the “mirrorlist” entries.
Uncomment the “baseurl” entries and change them to

http://vault.centos.org/4.9/os/$basearch

nJoy 😉

Installing EPEL Repository on CentOS

EPEL stands for Extra Packages for Enterprise Linux. This is a massive collection of packages that are very useful for the building of many modern stacks and include many tools for the running and maintenance of systems.

The homepage of EPEL is here: http://fedoraproject.org/wiki/EPEL.

You can browse the package set using repoview:

Installing on Centos 5.x & 6.x:

For EL5:

su -c 'rpm -Uvh http://mirror.switch.ch/ftp/mirror/epel/5/i386/epel-release-5-4.noarch.rpm'
...
su -c 'yum install puppet'

For EL6:

su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm'
...
su -c 'yum install puppet'

For EL7

sudo yum install epel-release

Fixing Warning: RPMDB altered outside of yum

What does it mean?

The yum message “Warning: RPMDB altered outside of yum.” or, as the yum message said for a few months, “Warning: RPMDB has been altered since the last yum transaction.” means some application has altered the rpm database (installed or removed a package) without going through the Yum APIs. This is almost always due to someone using rpm directly (Ie. rpm -ivh blah.rpm), but another possibility is an application built on top of the rpm APIs (Ie. smart, apt, zypp). While it’s possible that someone has hacked your machine and altered the rpmdb maliciously, it would have to be done poorly to trigger this warning.

Why has yum started to emit this warning?

There are three main sets of reasoning behind bringing this to the users attention.

New yum features require yum being “the” packaging API

There are now a few features in yum, requested by users of the package management system, that require yum is aware of all package actions on the system. Here a few of the current ones:

  • The most obvious example is “yum history”, which records when packages were installed, when and by whom. If yum is not involved in installing/updating/removing/etc. some packages then a lot of the benefits of “yum history” are gone. For instance there is no useful audit trail anymore, you can’t use “yum history list blah” and know you have all the instances where something happened to “blah”.
  • Yum now has it’s own database, for package information it wants to record but has no corresponding entry in the rpmdb, the obvious example is “the id of the repository that this package was installed from” but there are quite a few pieces of info. now.
  • Following on from the previous point, rpmdb versions are a significant feature for managing many machines by yum. They require information from the yumdb, so installing something via. yum on one machine but via. rpm on another would give the machines different “rpmdb versions”.

This is not a complete list, and as more package management features are implemented they are much more likely to be implemented at the yum layer than at the rpm layer. Not because rpm is bad, but for the same reasons that the above features were implemented in yum, it’s much easier and faster to implement them there.

 

Solution :

# yum clean all
 

How do I enable the Extra Packages for Enterprise Linux (EPEL) repository on Amazon AMI?

EPEL (Extra Packages for Enterprise Linux) is a repository of  (as the name implies) A collection of packages not directly released with the given linux distribution release cycle. By default these packages are not available but all the wiring in the amazon AMI instance is already done all one needs to do is enable it. To do so check the two following ways.

Modify /etc/yum.repos.d/epel.repo.

Under the section marked [epel], change enabled=0 to enabled=1.

To temporarily enable the EPEL 6 repository, use the yum enablerpo option :

--enablerepo=epel.

Example

yum search iperf  --enablerepo=epel

This will return :

How to use EPEL in Amazon AMI image
How to use EPEL in Amazon AMI image

 

That’s it short and sweet 😛