yum fails on my VPS / the RPM database on my VPS is corrupt

Under certain conditions the RPM database used by yum will become corrupt. Here is how to resolve this issue. You may see an error such as “Warning: RPMDB altered outside of yum” or “error: rpmdbNextIterator”

1. Take a backup FIRST, before trying to have rpm repair the database.

cd /var/lib
tar zcvf /var/preserve/rpmdb-[today's date].tar.gz rpm

Verify integrity with

cd /var/lib/rpm
rm -f __db*      # to avoid stale locks
/usr/lib/rpm/rpmdb_verify Packages

Next run the following:

mv Packages Packages.orig
/usr/lib/rpm/rpmdb_dump Packages.orig | /usr/lib/rpm/rpmdb_load Packages
/usr/lib/rpm/rpmdb_verify Packages
rpm -qa

Finally rebuild the database:

rpm -vv --rebuilddb

for the error :

error: rpmdbNextIterator


mv /var/lib/rpm/Pubkeys /var/lib/rpm/Pubkeys.backup
rpm --rebuilddb -vv to recreate the index.

from : https://bugzilla.redhat.com/show_bug.cgi?id=108915

reference : http://kbase.redhat.com/faq/docs/DOC-6904#

Enabling apc (php alternative cache) on your Centos VPS

Here is how to enabled php’s apc on a CentOS VPS:

1. yum -y install php-pear pcre-devel php-pear php-devel httpd-devel gcc
2. pecl install apc (press enter to accept the default response for each option)
3. echo “extension=apc.so” > /etc/php.d/apc.ini
4. service httpd restart
5. cp /usr/share/pear/apc.php /home/YOUR_USER_NAME/www/some_private_file_name.php

The apc.php page can be loaded to view the cache status. We recommend you rename it to something other than apc.php

Setting up yum for end-of-life CentOS 4 VPS

CentOS 4 is no longer supported by the developers and we do not recommend you install it. If you have a special case which requires CentOS 4, you will find that yum will not update or perform installs because the repository URL’s are no longer valid.

To make yum work with vault.centos.org, edit your :


to have these lines:

name=CentOS-$releasever - Base

#released updates
name=CentOS-$releasever - Updates

yum update, yum install, etc. will now work.

Webmin crashing / unresponsive on my VPS – how to fix?

Question: Webmin keeps crashing on my VPS. Why does this happen and how can I fix it?


From our experience, webmin seems to become non-responsive when running on “low memory” VPS’s (typically those with 256 megs of ram or less).

If you attempt to connect to webmin (port 10000 by default) and get an unable to connect message, do the following:

1. ssh in to your server
2. as root, type :

/sbin/service webmin restart

Note, that “service” will restart webmin on a RedHat/Centos based VPS. If you are running a different Linux flavor you’ll need to use the service management for that distribution.

You should also make sure webmin is set to start automatically on reboots by running:

/sbin/chkconfig webmin on

I can’t connect to webmin on my VPS


I tried to connected to webmin on my VPS today and got the error :

Firefox can’t establish a connection to the server at

(where is the IP of your VPS)

What is wrong?



This means webmin has crashed and is a warning sign that you are likely using more memory than your VPS has installed. On VPS’s with low memory, webmin seems to be one of the first things to lock up.

You can restart it by ssh’ing to the server and typing:

/sbin/service restart webmin

You could also reboot the entire VPS in your control panel as last resort if you do not have ssh access from your current location.

If you would like to purchase more memory contact support. Memory upgrades are quick and do not require any downtime to your VPS>

How do I upgrade php on a VPS?


The php version on my VPS is out of date. How do I update it?


Using the OS vendors normal update command can get you some updates (but perhaps not what you want – see below). For example on RedHat/CentOS run:

yum update php

However usually the OS vendors versions are not the latest. The update them to patch security issues but many times are far out of date from what you may require.

To update RedHat/CentOS to a newer php run these commands:

yum erase php-pdo php-xml php-mysql php php-common php-cli php-gd php-mbstring php-devel

yum install php53-pdo php53-xml php53-mysql php53 php53-common php53-cli php53-gd php53-mbstring

/sbin/service httpd restart

A note:

These are “unofficial” RPM’s as RedHat only official supports a particular (semi-old) version and backports security fixes to it – good for large corporate users but not so great for active developers). However the RPMS’s above are widely used in the community and most developers view them as trustworthy (just important to note that they are not actually from RedHat).

How does the switch over to a VPS from shared hosting take place?


I want to switch from my shared hosting to a VPS. How can this be done so that I have no downtime? What is the normal process?


Normally we do this:

1. Set your DNS TTL to a short value. Normally 3 minutes.

2. Clone your site (files and databases) to the VPS.

3. Send you the raw IP of the VPS to check things out on. Depending on the way your site is coded this may not work perfect (ie. your code keeps trying to redirect you to the proper domain name).

4. If all is well, you contact us and tell us to switch it over

5. We do one final sync of your db and files (in case anything changed from the time we first cloned your site). This step is optional. Let us know if you want a final sync done. If you’ve made tweaks to the VPS copy of the site you will NOT want this done as it will overwrite your changes.

6. The site goes live. If anything is wrong, you let us know and we switch it back

We keep your DNS TTL to about 3 minutes so if something is wrong, your users will pretty quickly (in theory no longer than 3 minutes) start hitting the “old” server again.

Shared hosting versus VPS downtimes


How often should I expect downtime on a shared account versus a VPS?


If you picked a random shared server, you could expect about one five minute outage every 5 months due to kernel upgrades. This is an average because there is no way to tell for certain when new (required – security related) kernels will be released. Think of a kernel update as a required security upgrade that needs a reboot to be installed.

On a shared server other outages are totally dependent on the machine itself and the hard to foresee mix of user websites loaded onto it. On a shared machine it is very hard to 100% stop a user with problems from affecting everyone else.

On a VPS you are in a much better position. You still have occasional reboots for kernel upgrades (we handle these automatically for you). All other parts of your server are totally private so you do not need to worry about other users causing downtime. As long as your own scripts do not cause out of memory and and other problems your VPS should run without issue.

Adding Silverlight support to Apache (mime.types)


Do I need to make any changes for the Apache webserver to support Silverlight apps?


In most cases, no changes need to be made.

If you are having problems, try adding:

application/manifest manifest
application/xaml+xml xaml
application/x-ms-application application
application/x-ms-xbap xbap
application/octet-stream deploy
application/vnd.ms-xpsdocument xps
application/xaml+xml xaml
application/x-silverlight-app xap

to your mime.types file

Don’t forget to restart apache with:

/usr/local/apache/bin/apachectl graceful

after you make the change.

Ruby, capistrano and a VPS

Q: What are my options for Rails?

A: Rails is pre-installed on your server (a few legacy servers may be missing it – if so, contact support). You can create a new app by typing :


at the command line.

An example is :

rails myapp
cd www
ln -s ../myapp/public/ myapp
cd ../myapp/
script/generate controller test
emacs app/controllers/test_controller.rb


def hello
render_text “Hello World!”

next go to:


capistrano is also pre-installed.

However if you are doing a lot of rails development, you may want to consider upgrading to a Virtual Private Server (VPS). A VPS will give you full root access so you can install things like mongrel and other app servers. Enter a support request to have your account upgraded to a VPS. Note: a fee will be involved. Be sure to ask support if you are not aware of VPS pricing.