Installing Multi-Byte PHP Functions

I received this error today:

Fatal error: Call to undefined function mb_strlen()

And it would look the same, no matter what multi-byte PHP function I might be using: mb_strpos(), mb_substr(), etc. And it is beginning to be important to have this extensions installed if you are working with international, multi-byte character sets like UTF-8.

The fix is super easy. All you need to do is install the PHP multi-byte extension with yum (if you're on CentOS or RHEL). Do the following from the command line:

yum install php-mbstring
service httpd restart

That installs the extension and restarts Apache. Then you're good to go!

Installing Memcached on CentOS

I have a web server running CentOS and wanted to get some good caching going for PHP use. This is how I installed memcached, from the command line:

• Install memcached
• yum install memcached
• Install Pecl (if you don't yet have it, installing pear installs pecl)
• yum install php-pear
• Install Pecl's Memcached package (for PHP)
• Install dependencies, as needed
• yum install php-devel
• yum install gcc
• yum install zlib-devel
• pecl install memcache
• Use a text editor to add "extension=memcache.so" to php.ini (may be in the /etc folder)
• Restart the service
• service memcached start 
• service httpd restart

And when you want some raw stats, you can get them via telnet:

• telnet localhost 11211

And type "stats" to see hits, misses and more!

Here are some examples of memcached use in PHP.

Partition and Mount a Drive on CentOS

I have a few servers over at Softlayer. I recently procured a monthly computing instance with an additional 200 gigs of drive space. Thing is, the extra HD space doesn't come partitioned, formated or mounted. So, here is what you do:

First things first. Find the name of the physical drive: fdisk -l

This command will return a list of drives and information about each. You should find one that hasn't been partitioned with a name like /dev/sdb (or in my case /dev/xvdc for a computing instance) or similar. Check the size of the drive to make sure it is what you are looking for.

Next, partition the drive: fdisk /dev/xvdc (using the name of the drive, of course)

Once in the fdisk utility, press p to print the partitions to the screen. There should be none, because you haven't created any yet. If there are, are you sure you are using the right drive?

Next press n to create a new partition, press p for a primary partition, 1 for the first partition, and then use the default first and last cylinder (unless you know what you are doing, of course). Once this is set up, you can press p to make sure it worked and then finally, and most importantly, press w to write the changes to disk.

In the previous command, you'll get a slightly different name for the partition you created. It probably added a letter, something like /dev/sdb1 or /dev/xvdc1 would be right. You'll need it to format the drive: mkfs -t ext3 /dev/xvdc1 (I've used the ext3 file system, here, because it suited me just fine and is probably the most common.)

Now, where would like the disk mounted? You'll have to create a folder as the mount point. If you want the disk to be used for a new /data directory, then you'll have to create a folder with this name: mkdir /data

Next, add the drive and mount point to the /etc/fstab file so that it will be mounted at boot time. Use your favorite text editor, as they say. I used vi /etc/fstab and I added a new row, matching the spacing of the other rows: /dev/xvdc1   /data    ext3   defaults   1 2

Lastly, you mount the drive using mount /dev/xvdc1 and you are all done.

Head on over to cd /data and check it out. Or run mount without parameters to check out the details.

PS. Here are a couple websites I used when I was working through this problem myself.

CentOS and "su: incorrect password"

I made a mistake. I was setting up CentOS and accidentily ran chown -R 0 /. Yep, a global & recursive ownership change. Not a good thing.

The first problem I noticed was that I couldn't use su -. It kept saying that I was using the "incorrect password" even though I was completely sure I was.

I after digging around, I found someone who had the same problem and a nice chap named Mike who, very impressively, pointed out the source of the problem (ie, the globaly recursive chown). His response: "He's got rather a mess, unfortunately." Uh oh.

Well, it seems that the mess wasn't as bad as I thought. After fretting and digging around the interwebs, I came across this article about resetting file permissions on RHEL (and CentOS by extension, of course). Hallelujah!!

Following the instructions there, I did this to fix my woes:

rpm --setperms -a

I am not convinced everything is back in its proper place and I will probably see more fallout from my careless command executing. BUT, I can successfully "su -" without any bogus password complaints. That I like.

VSFTPD & SELinux

This can be a fun combo to work with. SELinux, or Security Enhanced Linux, is the life of any party. And Google searches about SELinux-related problems makes it pretty evident that very few people have taken the time to understand how this program works. I ran across numerous people simply suggesting that you turn off SELinux if it is getting in the way.

Well, I didn't buy into this wholesale approach to getting things to work. Besides, I want a secure system and if SELinux is going to help me in the long run, I want it enabled.

VSFTPD, or Very Secure FTP Daemon, is a pretty standard FTP server. You can install it on CentOS systems (or RHEL, for that matter) by running "yum install vsftpd" from the command line. Once you get it installed you can make changes to the configuration file at "/etc/vsftpd/vsftpd.conf" using a file editor. Also, to make sure it is always running in the background run "chkconfig vsftpd on" and "service vsftpd restart" from the command line.

Make sure the configuration file is set up properly. Only give FTP access to a limited number of users (never include root), disable anonymous access and make sure users can only access the files they need (I recommend chroot-ing them).

This is only half the battle. Now that VSFTPD is running, how do you allow users to access their home directories? SELinux usually will get in the way of this. Well, there is a SELinux setting for this called "ftp_home_dir" and this will allow users to access their home directory via FTP. To set this, from the command line run

setsebool -P ftp_home_dir 1

Be sure to also check file permissions and file ownership, if you run into problems. A file must be writable for everyone if they do not specifically own it.

If this fails to grant you FTP access where you need it, or your set-up is slightly different, you can always allow the FTP daemon full access to all files by running

setsebool -P allow_ftpd_full_access 1

This is granting a bit more power to the FTP daemon than is necessary, but it is much better than just disabling SELinux all-together.

By the way, here is a great intro to CentOS & SELinux.

cURL and SSL

cURL is a nice little extension to PHP. You can read an intro here.

I use cURL a lot. It seems that do a lot of web applications that connect to other servers for transactions (like payment gateways). You can do SSL or HTTPS requests to other web hosts without validating their certificates but you leave yourself open to man-in-the-middle attacks. While this seems unlikely if you are running out of a data center, checking the certificate validity is too easy to skip.

The one thing that you must do for this to work is tell cURL where the CA-bundle (or CURLOPT_CAINFO) is located. I am running CENTOS 5.4 and found CA info at "/etc/pki/tls/certs/ca-bundle.crt". I can enable this with the following two lines added before curl_exec();

 curl_setopt($ch, CURLOPT_CAINFO, "/etc/pki/tls/certs/ca-bundle.crt");
 curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);