I’m finding that more and more software developers are being quite inconsiderate and are making code that requires PHP 5.3. Since many server-based and long-term support distros are still on PHP 5.2, this can make things difficult quickly.

I’ll share how I upgraded one of my servers, but I do need to let you know about some specifics about my setup as your setup may be different and require different steps to upgrade.

When I started, my system ran CentOS 5.5 and PHP 5.2.16. Now it is running CentOS 5.6 and PHP 5.3.3.

You won’t be able to follow these steps without root access, so that is definitely a requirement. I’m also running Apache. You may be using a different web server, but if you don’t know what I’m talking about, you are running Apache. I assume that if you run a different server, you will know what to change in my steps.

Upgrade CentOS 5.5 to CentOS 5.6

I found that CentOS 5.6, released earlier this year, had package support for PHP 5.3. That made me very excited. I thought that all I needed to do was to upgrade my distro, and I would be done (I would later find that I was naïve).

Fortunately, upgrading CentOS is very easy. I simply ran the following command to spawn a huge amount of work for the server:

[user@server ~]$ sudo yum update
[sudo] password for user:
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * addons: mirrors.tummy.com
 * base: centos.mirror.lstn.net
 * epel: fedora-epel.mirror.lstn.net
 * extras: mirror.ubiquityservers.com
 * updates: mirror.steadfast.net
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package amtu.x86_64 0:1.0.6-2.el5 set to be updated
---> Package asciidoc.noarch 0:8.6.5-1.el5.rf set to be updated
---> Package audit.x86_64 0:1.7.18-2.el5 set to be updated

...

Install       5 Package(s)
Upgrade     208 Package(s)
Remove        2 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Total download size: 309 M
Is this ok [y/N]: y
Downloading Packages:
(1/213): avahi-glib-0.6.16-10.el5_6.x86_64.rpm                                                                                                                                                                        |  15 kB     00:00
(2/213): avahi-glib-0.6.16-10.el5_6.i386.rpm                                                                                                                                                                          |  15 kB     00:00
(3/213): rng-utils-2.0-4.el5.x86_64.rpm                                                                                                                                                                               |  17 kB     00:00     

...

Complete!
[user@server ~]$ 

Notice the white “y” toward the bottom. Before it does anything, you must answer its question with a “y”. Just hitting enter will cancel the upgrade.

This will take between 5-30 minutes on average depending on the number of packages to be upgraded, the speed of your system, and your servers connection speed. So pop open a root beer and wait for everything to finish up.

Reboot the server

Since this should have installed a new kernel for your system, you will want to reboot so that this new kernel can be loaded.

Rebooting a server can be a scary thing. Make sure that you know how to contact your hosting company’s tech support in case there are any problems with connecting to the server after the reboot. Also make sure that you notify any people that may be upset about the reboot before you do it.

Upgrade PHP 5.2 to PHP 5.3

I booted up my system and found that my PHP version was not upgraded:

[user@server ~]$ php -v
PHP 5.2.11 (cli) (built: Jan 17 2011 01:47:19)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

This version of CentOS took the odd step of having both PHP 5.2 and PHP 5.3 packages. The main packages are 5.2 while another set with modified names are 5.3. For instance, the PHP 5.2 main package is php while the PHP 5.3 one is php53.

I still have no idea why they decided to do things this way, but I guess it has to do with some software not supporting 5.3 properly yet.

Since I couldn’t just install the php53 packages as they would conflict with the php packages, I had to remove all the existing PHP packages and install the new ones. This meant that I had to take stock of exactly what packages I had to remove and replace.

I used the yum commands list command to quickly get this information:

[user@server ~]$ yum list installed | grep php | cut -d' ' -f1
php.x86_64
php-cli.x86_64
php-common.x86_64
php-devel.x86_64
php-gd.x86_64
php-mbstring.x86_64
php-mysql.x86_64
php-mcrypt.x86_64
php-pdo.x86_64
php-pear.noarch
php-pgsql.x86_64
php-xml.x86_64
php-xmlrpc.x86_64
[user@server ~]$ 

The | cut -d' ' -f1 part at the end is just some fanciness to show only the package name and not the extra cruft.

Next I checked to make sure that those packages were available for php53:

[user@server ~]$ yum search php53 | cut -d' ' -f1 | grep php
php53.x86_64
php53-bcmath.x86_64
php53-cli.x86_64
php53-common.x86_64
php53-dba.x86_64
php53-devel.x86_64
php53-gd.x86_64
php53-imap.x86_64
php53-intl.x86_64
php53-ldap.x86_64
php53-mbstring.x86_64
php53-mysql.x86_64
php53-odbc.x86_64
php53-pdo.x86_64
php53-pgsql.x86_64
php53-process.x86_64
php53-pspell.x86_64
php53-snmp.x86_64
php53-soap.x86_64
php53-xml.x86_64
php53-xmlrpc.x86_64
[use@server ~]$ 

I quickly noticed that neither php53-mcrypt.x86_64 nor php53-pear.noarch were available. I would have to install these manually.

First, I shut down the Apache server as I didn’t want people going to broken pages as I did these updates:

[user@server ~]$ sudo service httpd stop
Stopping httpd:                                            [  OK  ]
[user@server ~]$ 

Next, I remove the old PHP packages:

[user@server ~]$ sudo yum remove php php-cli php-common php-devel php-gd php-mbstring \
 php-mysql php-mcrypt php-pdo php-pear php-pgsql php-xml php-xmlrpc
Loaded plugins: fastestmirror, priorities
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package php.x86_64 0:5.2.16-jason.1 set to be erased

...

Remove        13 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test

...

Complete!
[user@server ~]$ 

Finally, I installed the available replacement packages:

[user@server ~]$ sudo yum install php53 php53-cli php53-common php53-devel php53-gd \
 php53-mbstring php53-mysql php53-pdo php53-pgsql php53-xml php53-xmlrpc
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * base: centos.mirror.lstn.net
 * epel: fedora-epel.mirror.lstn.net
 * extras: mirror.ubiquityservers.com
 * updates: mirror.steadfast.net
Setting up Install Process

...

Install       2 Package(s)
Upgrade       0 Package(s)

Total download size: 18.5 M
Is this ok [y/N]: y
Downloading Packages:

...

Complete!
[user@server ~]$ 

Now it’s time to get the other PHP elements that were not available as packages.

Install PHP mcrypt

The php53-mcrypt package wasn’t available, so we have to install it manually. The following steps will accomplish this.

We first need to install the development package for mcrypt:

[user@server ~]$ sudo yum install php53-devel libmcrypt-devel
...

PHP’s mcrypt extension can be compiled and installed from the source code, so we need to download and unpackage the PHP 5.3.3 source. You can find a download link on the PHP releases page. I used wget to make the process a bit quicker:

[user@server ~]$ wget http://museum.php.net/php5/php-5.3.3.tar.gz
--2011-12-07 14:32:00--  http://museum.php.net/php5/php-5.3.3.tar.gz
Resolving museum.php.net... 67.23.255.166
Connecting to museum.php.net|67.23.255.166|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13921529 (13M) [application/x-gzip]
Saving to: 'php-5.3.3.tar.gz'

100%[=============================================================>] 13,921,529  2.04M/s   in 6.6s    

2011-06-24 19:10:40 (2.00 MB/s) - `php-5.3.3.tar.gz' saved [13921529/13921529]

[user@server ~]$ tar xf php-5.3.3.tar.gz
[user@server ~]$ 

Now we need to compile and install the mcrypt extension:

[user@server ~]$ cd php-5.3.3/ext/mcrypt/
[user@server mcrypt]$ phpize
Configuring for:
PHP Api Version:         20090626
Zend Module Api No:      20090626
Zend Extension Api No:   220090626
[user@server mcrypt]$ aclocal
[user@server mcrypt]$ ./configure
checking for egrep... grep -E
checking for a sed that does not truncate output... /bin/sed
checking for cc... cc

...

checking how to hardcode library paths into programs... immediate
configure: creating ./config.status
config.status: creating config.h
[user@server mcrypt]$ make
....

Build complete.
Don't forget to run 'make test'.

[user@server mcrypt]$ make test

Build complete.
Don't forget to run 'make test'.

=====================================================================
PHP         : /usr/bin/php
PHP_SAPI    : cli
PHP_VERSION : 5.3.3
ZEND_VERSION: 2.3.0

...

Do you want to send this report now? [Yns]: y

Please enter your email address.
(Your address will be mangled so that it will not go out on any
mailinglist in plain text): user@example.com

Posting to qa.php.net /buildtest-process.php

Thank you for helping to make PHP better.
[user@server mcrypt]$ sudo make install
Installing shared extensions:     /usr/lib64/php/modules/
[user@server mcrypt]$ 

Now all we have to do is set up the mcrypt.ini file so that the mcrypt extension loads with PHP. This file needs to reside at /etc/php.d/mcrypt.ini.

[user@server mcrypt]$ echo -e "; Enable mcrypt extension module\nextension=mcrypt.so" | \
 sudo tee /etc/php.d/mcrypt.ini
; Enable mcrypt extension module
extension=mcrypt.so
[user@server mcrypt]$ 

Install PHP Pear

Finally, I need to install PHP Pear. If you haven’t used it, it is essentially a code repository tool for easily installing, upgrading, and managing hosted code. It is basically PHP’s version of Perl’s CPAN.

Installing this is fairly straightforward.

[user@server ~]$ wget http://pear.php.net/go-pear.phar
--2011-06-24 15:18:22--  http://pear.php.net/go-pear.phar
Resolving pear.php.net... 78.129.214.25
Connecting to pear.php.net|78.129.214.25|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3680148 (3.5M) [application/octet-stream]
Saving to: `go-pear.phar'

100%[===============================================================>] 3,680,148    523K/s   in 7.3s    

2011-06-24 15:18:29 (491 KB/s) - `go-pear.phar' saved [3680148/3680148]

FINISHED --2011-06-24 15:18:29--
Downloaded: 1 files, 3.5M in 7.3s (491 KB/s)
[user@server ~]$ sudo php go-pear.phar 

Below is a suggested file layout for your new PEAR installation.  To
change individual locations, type the number in front of the
directory.  Type 'all' to change all of them or simply press Enter to
accept these locations.

...

Beginning install...
PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in phar:///usr/src/go-pear.phar/PEAR/Registry.php on line 1012
PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in phar:///usr/src/go-pear.phar/PEAR/Registry.php on line 1012
PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in phar:///usr/src/go-pear.phar/PEAR/Registry.php on line 1012
PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead in phar:///usr/src/go-pear.phar/PEAR/Registry.php on line 1012
Configuration written to /etc/pear.conf...
Initialized registry...

...

PEAR: Optional feature gtk2installer available (PEAR's PHP-GTK2-based installer)
PEAR: To install optional features use "pear install pear/PEAR#featurename"

The 'pear' command is now at your service at /usr/bin/pear
[user@server ~]$ 

Notice that ugly mess about the date() function. It’s PHP 5.3-specific. I posted how to fix it here.

Final Thoughts

All in all, this was much more complex than I had anticipated. I can understand why the CentOS devs had decided to make a separate set of packages for PHP 5.3, but it really has made things difficult. I do have to warn you that many other packages will start to take issue with this setup as they will have dependency requirements for the php package which naturally conflicts with the php53. This leads me to think that they have done this in a way that the repo was not supposed to support as the dependencies should not break in this fashion.

Oh well. Nothing is perfect.

I just updated one of my CentOS systems to PHP 5.3 (a chore best reserved for another blog post), and started to see the following warning popping up:

PHP Notice: in file index.php on line 15: date(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘America/Chicago’ for ‘CDT/-5.0/DST’ instead

Annoying to say the least. The fix is much easier than the message makes it seem.

PHP 5.3 now requires that you either have a timezone set in your php.ini file or that you pass the desired timezone via the date_default_timezone_set() function before calling the date() function.

I opened my server’s /etc/php.ini file and searched for timezone. My ini file had a section like the following:

[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
; date.timezone =

I uncommented the date.timezone line and added the timezone I wanted.

[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
date.timezone = 'America/Chicago'

There are two very important things to do in order for this to work properly for you:

1. Use a timezone that is appropriate for your needs. Use PHP’s List of Supported Timezones to find the timezone that works for you.
2. Since your server is likely to cache the PHP configuration, you will want to restart your web server process in order for the change to be recognized. The command to execute varies by system, but for most systems, the following will work:

   [user@server /etc]$ sudo service httpd restart
   [sudo] password for user:
   Stopping httpd:                                            [  OK  ]
   Starting httpd:                                            [  OK  ]
   [user@server /etc]$ 

   Of course, if you are already root, you won’t need to use sudo:

   [root@server /etc]# service httpd restart
   Stopping httpd:                                            [  OK  ]
   Starting httpd:                                            [  OK  ]
   [root@server /etc]# 

I recently wrote a script to dump data into CSV files. The CSV files work well for using in other scripts, but they are a bit difficult to read in order to verify that the data looks good. Sure, I could transfer the files to my local system and open them up in OpenOffice Spreadsheet or a similar program, but I want to do quick checks of the generated data and constantly copying the data and opening it up again in a program would just slow me down. Fortunately, there is a better way.

Using a combination of the cat, column, and less commands that are available from most *nix shells, the CSV data can be rendered into a nice table and quickly navigated. Here is an example:

[chris@host data]$ cat file.csv | sed -e 's/,,/, ,/g' | column -s, -t | less -#5 -N -S
      1 number_of_tests  execution_time min  execution_time max  execution_time avg  execution_time std_dev  peak_memory_usage min  peak_memory_usage max  peak_memory_usage avg  peak_memory_usage std_dev  real_memory_usage min
      2 449              0.2421700954        0.2522599697        0.24422667392717    0.0013405194115834      22062656               22067696               22062951.732739        552.24028841091            22282240
      3 416              0.2449610233        0.2619900703        0.24721734340337    0.0015257664849685      21295528               21300888               21295541.019231        262.48728836508            21495808
      4 446              0.2286360264        0.2422661781        0.23043336515404    0.001174508347353       20895976               20900800               20895987.03139         228.20177111936            20971520
      5 428              0.1955471039        0.2902140617        0.1981168762521     0.0046106433816399      18045464               18048784               18045487.271028        276.98063531264            18087936
      6 436              0.2208828926        0.2558329105        0.22297720351353    0.0021463518368546      18717960               18723192               18718020.238532        557.06025400191            18874368

The output is easy to navigate with the cursor keys and is perfect for quickly verifying the generated data.

To use for your files, simply replace file.csv in the above example with your file’s name. The -#5 determines how many columns to scroll when using the left and right arrow keys. You can increase or decrease this as needed to make navigating easier.

For those interested, I’ve tested this on Debian-based (Ubuntu, Mint, etc) and Redhat-based (CentOS) systems, and it works on all of them.

I updated the command to fix a problem with handling empty entries, such as “…,data,,data,…”. The sed command takes care of changing those empty values to a space.

Yet another tale from trying to run a Perl script with the setuid bit turned on. See my earlier post on fixing “Can’t do setuid (cannot exec sperl)” for details about why running perl scripts with setuid bits is a special case.

I tried to run my script and I got the following message:

[user@server ~]$ run-script
Insecure $ENV{PATH} while running setuid at ~/run-script line 4.

The basic idea that this message is trying to get across is that an environment variable that is being used may contain data that could open up an attack vector. The way to fix this is by setting the variable to a set of defaults that don’t come from the user and thus are less susceptible to being manipulated by someone in order to break the security of the system.

In this case, my script executed a program on the shell. Since shell interpretation comes into play, the $PATH variable is looked at to decide where the program could be located. This is an attack vector as someone could just change that variable to cause their own code to be called, thus escalating their code’s privileges without your knowledge.

In order to avoid this, I set the $PATH variable to a restricted set for use in the script by adding the following in the script before my shell call:

$ENV{"PATH"} = "/usr/bin";

This may need to be modified to meet your specific needs. In addition to making this change, I went ahead and changed the call to the shell program to be an absolute reference to the program in order to further mitigate any potential issue, such as aliases.

I recently needed to run a perl script with setuid bit set. This allows the script to run as the user the script’s file is owned by. In this case, I needed the script to run as root.

Since doing this can be very dangerous, Perl does something very nice by default: If you have the setuid bit set on the script, it forces the script to run in Taint Mode which helps to ensure proper sanitation of the environment and inputs. By doing this, Perl can help lock down possible attack vectors that can compromise the security of your script. This isn’t perfect however, so I do recommend that you read up on Perl’s security measures.

So now down to the main point of this post. I tried to run the script with the setuid bit set, and I got the following error message:

[user@server ~]$ run-script
Can't do setuid (cannot exec sperl)

Well that certainly puts a damper on things. Fortunately, the solution is easy. There is simply an additional package that needs to be installed to provide the wrapper program that puts this Perl security in place.

For Debian (Ubuntu, Mint, etc as well), run the following:

[user@server ~]$ sudo apt-get install perl-suid

For CentOS, run the following:

[user@server ~]$ sudo yum install perl-suidperl

All the content on my site was gone. When I went to investigate, I found my error log was filled with the following error:

WordPress database error Table ‘./database_name/prefix_posts’ is marked as crashed and should be repaired for query SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(ID) as posts FROM prefix_posts  WHERE post_type = ‘post’ AND post_status = ‘publish’ GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC  made by require, require_once, include, do_action, call_user_func_array, flexx_after_content, get_sidebar, locate_template, load_template, require_once, dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, WP_Widget_Archives->widget, wp_get_archives

A very scary looking error, but it was easy to fix.

My Preferred Repair Method

[user@server ~/public_html]$ mysql -u user -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1120449
Server version: 5.1.48 MySQL Community Server (GPL)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> connect database
Connection id:    1120477
Current database: database

mysql> select * from prefix_posts limit 1;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1120568
Current database: database

ERROR 145 (HY000): Table './database/prefix_posts' is marked as crashed and should be repaired
mysql> repair table prefix_posts;
+-----------------------+--------+----------+----------+
| Table                 | Op     | Msg_type | Msg_text |
+-----------------------+--------+----------+----------+
| database.prefix_posts | repair | status   | OK       |
+-----------------------+--------+----------+----------+
1 row in set (3.56 sec)

mysql> select * from prefix_posts limit 1;
+----+-------------+---------------------+---------------------+--------------+------------+---------------+--------------+-------------+----------------+-------------+---------------+-----------+---------+--------+---------------------+---------------------+-----------------------+-------------+------------------------------------------------------------+------------+------------+----------------+---------------+
| ID | post_author | post_date           | post_date_gmt       | post_content | post_title | post_category | post_excerpt | post_status | comment_status | ping_status | post_password | post_name | to_ping | pinged | post_modified       | post_modified_gmt   | post_content_filtered | post_parent | guid                                                       | menu_order | post_type  | post_mime_type | comment_count |
+----+-------------+---------------------+---------------------+--------------+------------+---------------+--------------+-------------+----------------+-------------+---------------+-----------+---------+--------+---------------------+---------------------+-----------------------+-------------+------------------------------------------------------------+------------+------------+----------------+---------------+
| 12 |           8 | 2008-05-20 10:09:49 | 2008-05-20 15:09:49 |              | 308image1  |             0 |              | inherit     | open           | open        |               | 308image1 |         |        | 2008-05-20 10:09:49 | 2008-05-20 15:09:49 |                       |           0 | http://gaarai.com/wp-content/uploads/2008/05/308image1.gif |          0 | attachment | image/gif      |             0 |
+----+-------------+---------------------+---------------------+--------------+------------+---------------+--------------+-------------+----------------+-------------+---------------+-----------+---------+--------+---------------------+---------------------+-----------------------+-------------+------------------------------------------------------------+------------+------------+----------------+---------------+
1 row in set (0.00 sec)

mysql> exit
Bye
[user@server ~/public_html]$ 

For me, this was the easiest and quickest way to repair the table.

Repairing Tables with phpMyAdmin

For you, you might prefer to use phpMyAdmin. Fortunately, repairing a table with phpMyAdmin is easy.

1. Log in to your phpMyAdmin or connect to it via your cPanel back-end.
2. Select the database with the crashed table.
3. Put a checkmark next to each crashed table.
4. Select “Repair table” from the “With selected:” drop down at the bottom of the list.
5. Let phpMyAdmin do its thing.

I’m working on building an ideal server setup that allows for both PHP 4 and PHP 5 on Apache with suPHP (I’ll blog about this later). While testing my PHP 4 build, I got the following error:

Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in /var/www/test-php.php on line 3
Couldn’t authenticate with MySQL

The code I used to test this is quite simple:

<?php

if ( false === ( $db = mysql_connect( 'localhost', 'username', 'password' ) ) )
    die( "Couldn't authenticate with MySQL" );

if ( false === mysql_select_db( 'database' ) )
    die( "Couldn't connect to database" );

echo "Yay!";

?>

After digging around for a bit, I found that mixing PHP 4 with a MySQL version greater than or equal to 4.1 causes this problem. MySQL 4.1 introduced a new password caching scheme that PHP 4 can’t work with.

The solution is to update the database user’s password using the OLD_PASSWORD function of MySQL. For example:

[chris@office ~]$ mysql -u root -p mysql
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 267
Server version: 5.1.41-3ubuntu12.1 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> update user set Password=OLD_PASSWORD('password') WHERE User='username';
Query OK, 0 rows affected (0.02 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql>

Note the underlined areas. That is where you’ll want to provide your own username and password.

Once you’ve followed these steps, both PHP 4 and PHP 5 will be able to communite with the database.

Thanks to digitalpeer for providing the answer to my issue.

I recently had a issue getting MySQL to read a specific database. Each time I tried to manually query a table in the database, I received the following error message:

ERROR 1018 (HY000): Can't read dir of './default/' (errno: 13)

I’ve seen this message before as it means that there is a permissions issue. I checked the ownerships and permissions, and everything seemed to be in order.

The only thing special about this database is that I have it symlinked to another partition. This has always worked in the past, so I was stumped.

The problem turned out to be that Ubuntu has AppArmor. This software sets up rules that prevent software from gaining access to different areas of the file system. In my case, AppArmor was preventing read and write access to the actual location of my database files.

The solution was quite easy: First, I added the path that I wanted MySQL to have access to in the AppArmor configuration file for MySQL. Second, I restarted the apparmor service. Here’s the technical details:

1. On my system, the configuration file that controls MySQL permissions through AppArmor are located at /etc/apparmor.d/usr.sbin.mysqld. The following shows the contents of the file as it now exists:

   # vim:syntax=apparmor
   # Last Modified: Tue Jun 19 17:37:30 2007
   #include 
   
   /usr/sbin/mysqld {
     #include
     #include
     #include
     #include
     #include 
   
     capability dac_override,
     capability sys_resource,
     capability setgid,
     capability setuid,
   
     network tcp,
   
     /etc/hosts.allow r,
     /etc/hosts.deny r,
   
     /etc/mysql/*.pem r,
     /etc/mysql/conf.d/ r,
     /etc/mysql/conf.d/* r,
     /etc/mysql/my.cnf r,
     /usr/sbin/mysqld mr,
     /usr/share/mysql/** r,
     /var/log/mysql.log rw,
     /var/log/mysql.err rw,
     /var/lib/mysql/ r,
     /var/lib/mysql/** rwk,
     /var/log/mysql/ r,
     /var/log/mysql/* rw,
     /var/run/mysqld/mysqld.pid w,
     /var/run/mysqld/mysqld.sock w,
     /home/sites/default/mysql/ rw,
     /home/sites/default/mysql/* rw,
   
     /sys/devices/system/cpu/ r,
   }

   The two lines in bold show what I added to the configuation. The first line gives read and write access to the directory itself while the second gives read and write access to the files contained in the directory.

2. After saving the configuration changes, I simply needed to restart the AppArmor daemon. I did this with the following command:

   [chris@rommie ~]$ sudo service apparmor restart
    * Reloading AppArmor profiles
   Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox

One of my all-time most popular posts was how to upgrade to Firefox 3.5 in Ubuntu 9.04. Now it’s Firefox 3.6′s turn to be installed on my system that is now running Ubuntu 9.10.

The team working on Firefox have put a ton of effort into this release and, in order to make our browsing lives safer and faster, rolled a number of features scheduled for 3.7 into this release. Thanks for all the hard work guys.

Read the 3.6 release announcement for details about what is new with this release.

So now onto the installation. Here are the commands that I ran in terminal to install 3.6.

[chris@rommie ~]$ cd /tmp/
[chris@rommie /tmp]$ wget "http://download.mozilla.org/?product=firefox-3.6&os=linux&lang=en-US"
--2010-01-21 11:41:08--  http://download.mozilla.org/?product=firefox-3.6&os=linux&lang=en-US
Resolving download.mozilla.org... 63.245.209.58
Connecting to download.mozilla.org|63.245.209.58|:80... connected.
...

100%[=============================>] 10,161,471   924K/s   in 11s     

2010-01-21 11:41:20 (899 KB/s) - `firefox-3.6.tar.bz2' saved [10161471/10161471]

[chris@rommie /tmp]$ tar xvjf firefox-*.bz2
tar: Record size = 8 blocks
firefox/
firefox/update.locale
firefox/plugins/
firefox/plugins/libnullplugin.so
...
firefox/defaults/autoconfig/platform.js
firefox/defaults/autoconfig/prefcalls.js
firefox/libmozjs.so
[chris@rommie /tmp]$ sudo cp -r firefox /usr/lib/firefox-3.6
[sudo] password for chris:
[chris@rommie /tmp]$ sudo mv /usr/bin/firefox /usr/bin/firefox.old
[chris@rommie /tmp]$ sudo ln -s /usr/lib/firefox-3.6/firefox /usr/bin/firefox-3.6
[chris@rommie /tmp]$ sudo ln -s /usr/bin/firefox-3.6 /usr/bin/firefox

Simply run each command listed in white in your terminal to upgrade your system with the latest release version of Firefox.

After running these commands, close out Firefox, wait a few seconds to let everything shut down properly, and run Firefox again. If all the steps were executed properly and without error, you should be running 3.6. You can click Help > About Mozilla Firefox to confirm.

Happy browsing.

My dual monitor setup didn’t work properly in Ubuntu 9.04, Jaunty Jackalope. Fortunately, it does work properly in 9.10, Karmic Kaola. However, this newfound dual monitor setup has given me a new problem: how do I move my panels to the secondary monitor?

My office machine is a laptop. When I get in the office, I hook it up to a 24″ LCD. I’d like to use this external monitor as the primary, which means that I definitely want to have my panels display on it. However, as much as I tried to drag the panels around or play around with settings, there just didn’t seem to be a way to get them over there. However, I just figured it out.

By default, panels are set to expand. This means that the panels will span the entire width or height of the section of the window they occupy. If the expand option is disabled, they turn into self-sizing bar that can be dragged to different edges or centered.

Having the expand option disabled also allows you to grab and edge of the panel and drag it to another screen. Once on the screen you want it on, simply re-enable the expand option and you now have the panel on another screen.

Here’s a step-by-step way of moving a panel to another screen:

1. Right-click the panel you wish to move and select “Properties”.
2. Uncheck the “Expand” option under the “General” tab.
3. Grab one of the edges of the panel by clicking on the left or right end (top or bottom end for vertical panels).
4. Drag the bar to the desired screen and position.
5. Check the “Expand” option in the “Panel Properties” window and click “Close”.