CentOS networking not active after installation

I needed to install a CentOS 6.4 server in a VM and after installing I was not able to hit anything on the Internet, or any network for that matter.  When I tried using the yum packages manager I received the error “Couldn’t resolve host ‘mirrorlist.centos.org…” and I was at a loss on what to do next.  I was not able to ping anything.

This led me to look into the networking and and upon opening the /etc/resolv.conf I found it totally empty.  So I then opened /etc/sysconfig/network-scripts/ifcfg-eth0 and found the issue.  The line “ONBOOT” was set to “no”.

The complete file /etc/sysconfig/network-scripts/ifcfg-eth0 after I altered it: (NOTE: the only thing I altered was the ONBOOT flag.)

DEVICE=eth0
HWADDR=09:00:27:D7:61:8D
TYPE=Ethernet
UUID=q93perfj-earf-ewrf-wqer-546877145475
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp

After changing “ONBOOT” to “yes”, then rebooted for the configuration to take effect, all is good now.  I probably could have simply done a networking restart, but reboot on a fresh system was pretty fast.

Install APC (alternative PHP cache) on RedHat RHEL 5

After attending php|tek 2009 I decided it was finally time for me to play with APC, and at least install it on a server to see what all of the excitement is about. After all, if it is good enough for Facebook it must be pretty beneficial, right?

According to the documentation the following command is what it takes to install:

pecl install apc

However, then I tried this I quickly received an error stating “phpize: command not found”. So after a little searching I discovered that I needed to install php-devel.i386 to enable pear to install packages. (You may also need to install autoconf, automake and libtool to do phpize. I must have already had them installed.)

sudo yum install php-devel.i386

Note: I used sudo, but you can also use su to change to the root user and then run the command as root.

Now after installing that, which also installed a couple of dependencies and updated a couple of other applications, I figured I would be all set. To the contrary I tried the install apc command again and I received one prompt asking:

Use apxs to set compile flags (if using APC with Apache)? [yes]:

I received a new error after answering “yes” :

Sorry, I was not able to successfully run APXS.  Possible reasons:
 
1.  Perl is not installed;
2.  Apache was not compiled with DSO support (--enable-module=so);
3.  'apxs' is not in your path.  Try to use --with-apxs=/path/to/apxs
The output of apxs follows
/tmp/tmpArfGXr/APC-3.0.10/configure: line 3196: apxs: command not found
configure: error: Aborting
ERROR: `/tmp/tmpArfGXr/APC-3.0.10/configure --enable-apc-mmap=yes
--with-apxs' failed

After a few minutes of searching I found a post somewhere that informed me that httpd-devel.i386 also needed to be installed.

sudo yum install httpd-devel.i386

Once the package installed, along with a few more dependencies and updates, I was then ready to try again. This time all went well, and APC was installed.

One final step was to activate it in the php.ini file. I added the following:

extension=apc.so
apc.enabled = On

Next I was ready to restart Apache and see APC in action:

sudo /etc/init.d/httpd restart

After creating a quick phpinfo() call I could now see that the APC module was indeed active. Once I copied the apc.php file that comes with the APC install files into a web accessible directory (preferably password protected) I was clearly able to see stats associated with APC.

There is much more you can do with APC settings, etc. However, that is another story for another time. Here are a couple of links to help get you started though.
C7y Tutorial
Pecl page

Installing mhash on RHEL 4 and PHP 4.3.9

Recently I had a customer that was receiving errors from an Authorize.Net web submit form in their shopping cart. The error simply stated:

“The gateway no longer supports the requested method of integration.”

While doing some digging I found that they were using a very old web submit method that Authorize.Net no longer supported. There were two ways to fix the problem:

  1. Change to AIM method of submission, which required an SSL certificate that the client did not have.
  2. Change to SIM method of submission, which required either PHP 5.1.2 installed to use the hash_hmac function, or for PHP 4.3.9 it required that mhash be installed on the server.

Since the client did not want to spend the extra cash for the SSL certificate, and I could not install PHP 5.1.2 because I had too many other clients on the server that were not ready for the upgrade, I decided to do some searching for a way to install mhash.

It turned out that the Red Hat repositories did not carry php-mhash for RHEL 4, so this meant I needed to look in other areas. After reading many different blog and BB postings saying that it required an install, then a recompile of PHP I started to get a little worried. I did not look forward to recompiling PHP.

Finally I found some posts that brought a ray of hope. There are RPMs available to install php-mhash without the PHP recompile, but it required that libmhash be installed first. Here are the steps I followed:

  • I went to http://dag.wieers.com/packages/libmhash/ and downloaded the newest version of libmhash for my server.
  • Then I installed using the following to satisfy dependencies of mhash:
    rpm -iv libmhash-0.9.1-1.rhel3.dag.i386.rpm
  • Next I downloaded the php-mhash by using:
    wget ftp://rpmfind.net/linux/sourceforge/p/ph/phprpms/php-mhash-4.3.2-19.ent.2.i386.rpm
  • I followed that by installing it using:
    rpm -iv php-mhash-4.3.2-19.ent.2.i386.rpm

After following those steps I created a phpinfo script to see that everything went well:

<?php
phpinfo();
?>

I could now plainly see that mhash was installed perfectly, and with further tests I confirmed it was working.