FreeBSD.org Was Compromised. What Should You Do Next?

In case you are not aware this bad news. FreeBSD.org was compromised on September 17, 2012. Good news is that the compromise was caused by a human error (a stupid developer leaked a SSH private key somewhere), which has nothing to do with the code quality of the FreeBSD. 🙂 Bad news is that this may affect you if you use port. 🙁

The compromise is believed to have occurred due to the leak of an SSH key from a developer who legitimately had access to the machines in question, and was not due to any vulnerability or code exploit within FreeBSD.

We unfortunately cannot guarantee the integrity of any packages available for installation between 19th September 2012 and 11th November 2012, or of any ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors. Although we have no evidence to suggest any tampering took place and believe such interference is unlikely, we have to recommend you consider reinstalling any machine from scratch, using trusted sources.

In short, the port tree was affected from September 19, 2012 to November 11, 2012. If you downloaded the ports in between this period, you are likely a victim of this incident. 🙁 Here is how to clean up the mess:

Stop using cvsup/csup to update your port. Use portsnap instead.

If you already used portsnap, do the following:

sudo portsnap fetch extract
sudo portsnap upgrade

If you have no idea what is portsnap, here is a quick tutorial:

First, install the portmaster and portupgrade. Port-Upgrade downloads the new ports to your server and Port-Master updates your applications based on the downloaded ports.

sudo pkg_add -r portupgrade portmaster

Download all ports. Notice that this is one-time work.

sudo portsnap fetch extract

If you decide to update your port tree, run the following:

sudo portsnap fetch update

Or if you like to run it in a cron job, run the following instead:

sudo nano /etc/crontab

#Run every three hours
0       */3     *       *       *       root    portsnap -I cron update && pkg_version -vIL= >/dev/null 2>&1

Now you have an updated port tree. Next you will need to update your applications based on your local port tree:

sudo portmaster -Dai

That’s it.

And remember, NEVER put your SSH private key in a public area.

–Derrick

Our sponsors:

[FreeBSD]The devel/pkg-config port moved to devel/pkgconf; Reason: pkg-config has been replace by pkgconf; pkgconf-0.8.5 conflicts with installed package(s): pkg-config-0.25_1

FreeBSD is designed for users who got lots of spare time. Every once a while, it will give you some troubles (or “snacks” in programmer language), which help you to burn some of your spare time. If you cannot handle those troubles, then FreeBSD is not for you.

Although FreeBSD is a rock solid operating system, it is not smart enough to tell whether the owners (i.e., me and you) got plenty of spare time or not.

Anyway, comparing to Windows Server, I think FreeBSD is considered an honor student.

Okay, let’s go back to the error message. When I tried to update FreeBSD, I saw the following error:

===>>> All >> pkg-config-0.25_1 (1/1)

        ===>>> The devel/pkg-config port moved to devel/pkgconf
        ===>>> Reason: pkg-config has been replace by pkgconf

===>  pkgconf-0.8.5 conflicts with installed package(s):
      pkg-config-0.25_1

      They install files into the same place.
      You may want to stop build with Ctrl + C.

Again, this is an old-school error. The port-maintainer decided that the app A is too old, and he likes to replace it by app B. We all love the new stuffs, but we want the transition goes smooth. Apparently, it seems that the port-maintainer totally forgot about it.

So here is how to solve this problem:

sudo pkg_info | grep pkg

You will see something like the following:

pkg-config-0.25_1   A utility to retrieve information about installed libraries

Let’s delete it.

sudo pkg_delete -f pkg-config-0.25_1

Verify that the package has been deleted:

sudo pkg_info | grep pkg

Now try to install the package again:

cd /usr/ports/devel/pkgconf
sudo make install clean

That’s it!

–Derrick

Our sponsors:

[FreeBSD]How to run PECL Tokyo Tyrant in PHP 5.4

After upgrading to PHP 5.4.3 (which is the first version of PHP 5.4 available in the FreeBSD port), I found that the pecl-tokyo_tyrant could not be compiled. Here is the error messages:

cd /usr/ports/databases/pecl-tokyo_tyrant
sudo make
===>  pecl-tokyo_tyrant-0.6.0 cannot install: doesn't work with PHP version : 5 (Doesn't support PHP 5).
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant.
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1827: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1867: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_table_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1911: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_query_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1936: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_iterator_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_query_object_new':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2001: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_iterator_object_new':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2052: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_object_new_ex':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2090: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'zm_startup_tokyo_tyrant':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: 'php_tokyo_tyrant_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: (Each undeclared identifier is reported only once
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: for each function it appears in.)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2171: error: 'php_tokyo_tyrant_table_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2176: error: 'php_tokyo_tyrant_query_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2182: error: 'php_tokyo_tyrant_iterator_class_methods' undeclared (first use in this function)
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0.
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant.

Basically, it means that the pecl-tokyo_tyrant is not happy with the new version of PHP 5.4. I’ve tried several methods, including using pkg_add, compiling from source, copying a working tokyo_tyrant.so etc, unfortunately none of these methods works.

Finally, I found that the maintainer of this package has made a new version available(0.6.2) at github. Here is how I did it:

First, go to here to grab the source code. Make sure that you download the tag.gz version because it has the file attribute available.

Second, let’s remove the pecl-tokyo_tyrant from your system. You can either do it in the port or pkg_delete:

From port:

cd /usr/ports/databases/pecl-tokyo_tyrant
sudo make deinstall

Or using pkg_delete:

sudo pkg_delete pecl-tokyo_tyrant-0.6.0

Now, extract the files and compile it from source:

tar -zxvf mkoppanen-php-tokyo_tyrant-0.6.0-2-gb0d7e0c.tar.gz
cd mkoppanen-php-tokyo_tyrant-b0d7e0c
sudo phpize
sudo ./configure
sudo make
sudo make install

and don’t forget to include the .so file in your configuration:

sudo nano /usr/local/etc/php/extensions.ini

Add the following (if not available) to the end of the file:

extension=tokyo_tyrant.so

Finally, let’s restart the Apache:

sudo apachectl stop
sudo apachectl start

That’s it! Have fun with Tokyo Tyrant with PHP 5.4.

–Derrick

Our sponsors:

[PHP/FreeBSD]===>>> The databases/php5-sqlite port has been deleted: Removed from core php ===>>> Aborting update

When PHP 5.4 was available few months ago, I was hesitated to upgrade my FreeBSD box to upgrade to 5.4, because it comes with lots of big changes, including removing LOTS of old stuffs that were available in 5.3 or earlier versions.

Today PHP 5.4.3 becomes available in FreeBSD ports. I guess it is stable enough and I should give it a try, and I am glad that I tried it in my test machine first.

Warning: Before you upgrade to PHP 5.4, make sure that you are not using any of the following packages, because they are not compatible with the PHP 5.4. Unfortunately, I don’t have a solution yet. Basically, I could not get them compiled.

  • eAccelerator: /usr/ports/www/eaccelerator/
  • PECL-TokyoTyrant: /usr/ports/databases/pecl-tokyo_tyrant/ (Updated: I just came up a solution here)

When I performed the upgrade using the following command:

sudo portsnap fetch update
sudo portmaster -Da

I got the following error message:

===>>> The databases/php5-sqlite port has been deleted: Removed from core php
===>>> Aborting update

The reason why you see this problem because php5-sqlite is no longer available in PHP 5.4. In order to solve this problem, you will need to delete the php5-sqlite extension.

cd /usr/ports/lang/php5-extensions
sudo make config

Uncheck the following: sqlite3 support

Now, deinstall this port. Yes, let’s remove it and install it again. (I’ve tried the reinstall option and it didn’t work, so let’s stick with deinstall and install.

sudo make deinstall clean install clean

Now let’s find out which php-SQLite we should delete:

pkg_info | grep php5-sqlite

In my case, I deleted this one:

sudo pkg_delete php5-sqlite-5.3.13

Now upgrade the port again and FreeBSD should be happy about it. Enjoy PHP 5.4.

–Derrick

Our sponsors:

[Solved]Problem to Update OpenLDAP in FreeBSD

Recently, I found the following error message when updating my FreeBSD system regarding to the OpenLDAP:

===>  Installing for openldap-client-2.4.31
===>   Generating temporary packing list
===>  Checking if net/openldap24-client already installed
===> Creating users and/or groups.
Using existing group `ldap'.
Creating user `ldap' with uid `389'.
pw: user 'ldap' already exists
*** Error code 74

Stop in /usr/ports/net/openldap24-client.
*** Error code 1

Stop in /usr/ports/net/openldap24-client.

And I don’t use LDAP in particular, however it affects other applications that use LDAP, e.g., PHP

php -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/ldap.so' - Shared object "libldap-2.4.so.8" not found, required by "ldap.so" in Unknown on line 0
PHP 5.3.10 with Suhosin-Patch (cli) (built: Feb 14 2012 16:59:15)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator

It is very simple to solve this problem. All you need is to remove the user ‘ldap’, and install the port again. First, let’s remove the user ‘ldap’ first:

sudo vipw

You will see this line:

ldap:*:389:389::0:0:OpenLDAP Server:/nonexistent:/usr/sbin/nologin

Remove the line by pressing ‘dd’, hit ‘ESC’ button, and then press ‘:wq’ to save the file and quit the editor.

After that, let’s clean the port and run the update again:

cd /usr/ports/net/openldap24-client
sudo make clean
sudo make install clean

That’s it. Your LDAP will be happy and your applications (such as PHP) will not complain.

Our sponsors:


–Derrick

[FreeBSD] Samba does not start after updating to 3.5.14

After I updated my Samba to 3.5.14 on my FreeBSD box today, it stopped working. I couldn’t connect to the Samba server from my Windows clients. Initially, I thought it was the memory cache issues, and I thought the problem would be solved by rebooting both machines. Unfortunately, it didn’t work. Therefore, I accessed to the server and check the cause of the problem.

First, I found that Samba was not evening running.

ps -ax | grep smb

So I started the Samba service manually:

sudo /usr/local/etc/rc.d/samba start

And it returned me the following message:

Cannot 'start' samba. Set winbindd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.

Oh that was easy. All I need to do was to modify my rc.conf:

#Samba service
samba_enable="YES"
winbindd_enable="YES"

And then I started the Samba again:

sudo /usr/local/etc/rc.d/samba start

Yay, Samba is up and running again!

–Derrick

Our sponsors:

[Solved]Failed to enable the ‘dataready’ Accept Filter

After I updated the Apache to 2.2.22 for my FreeBSD box today, I got a problem:

#apachectl stop
#apachectl start

[warn] (2)No such file or directory: Failed to enable the 'dataready' Accept Filter

If you search for Failed to enable the ‘dataready’ Accept Filter on Google, you probably will find a lot of posts about this solution, like the following:

#kldload accf_http

Or include the following in the boot loader (/boot/loader.conf):

accf_http_load="YES"

However, even you already done these two things, this problem still exists.

#kldload accf_http
kldload: can't load accf_http: File exists

Why? That’s because the problem is not coming from accf_http. Instead, the problem is the missing dataready filter, which is accf_data. To solve this problem, simply do the following. First, update the /boot/loader.conf and add the following into the file:

accf_data_load="YES"

Of course, any changes to the boot loader requires a reboot. If you don’t want to reboot the machine, simple load the module manually and restart the Apache, i.e.,

#kldload accf_data
#apachectl stop
#apachectl start

That’s it! Apache will stop complaining the dataready filter and will work happily.

–Derrick

Our sponsors:

[PHP]imagecreatefrompng Error (After upgrading FreeBSD)

Today, I found that one of my PHP scripts stop working. After some investigations, I found that it was the function, imagecreatefrompng, which caused the problem.

Interestingly, other similar functions such as imagecreatefromgif and imagecreatefromjpeg were completely working fine. The program stopped working when calling imagecreatefrompng only.

Initially, I thought the problem was coming from the PHP side. Therefore, I tried to get the error messages as many as possible, such as PHP error (error_reporting), Apache error (error_log), and even system error (dmesg). Unfortunately, I couldn’t find anything.

The script was working completely fine until I upgraded the system. So I think the problem may come from a missing library. To give you some background, here is how imagecreatefrompng works. First, your program calls imagecreatefrompng, which involves the GD library. GD library calls a PNG function in your system (possibly libpng) to process the PNG file. Since the program comes with from the system library, PHP / Apache will not report anything about it.

Since it will be too complicated to identify which library caused the problem, I decide to reinstall all ports. It sounds a very long process but it wasn’t at all. It only took 20 minutes to finish the whole thing. So here is what I did:

#FreeBSD
#sudo portmaster -fa

After the installation is completed, I rebooted the machine and everything worked again!

Enjoy!

–Derrick

Our sponsors:

[FreeBSD+ZFS]One or more devices has experienced an error resulting in data corruption. Applications may be affected.

When you check the ZFS status, you may find the following error message: One or more devices has experienced an error resulting in data corruption. Applications may be affected.. There can be million reasons to cause this error message showing up. Of course, 99% of them are caused by hardware failure, such as bad hard drives, broken cables, defective motherboard, or even bad memory. In this article, I am assuming that you already eliminated these possibilities, and have scratched your head for hours, and still have no clue which part went wrong. In fact, that’s what I did today.

Long story short. Here is how I experienced this error:

FreeBSD: 8.2-> 9.0
ZFS: 4 -> 5
ZPool: 15 -> 28

My system was working fine (FreeBSD 8.2; ZFS ver. 4, Zpool ver. 15), everything seems perfect. After I upgraded my system to FreeBSD 9, I upgraded the ZFS and Zpool to ver.5 and ver. 28, respectively. Everything seemed working fine until I check the status:

sudo zpool status -v
#sudo zpool status -v
  pool: storage
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
config:

        NAME        STATE     READ WRITE CKSUM
        storage     ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0
            ada4    ONLINE       0     0     0
            ada5    ONLINE       0     0     0
            ada6    ONLINE       0     0     0
            ada7    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        storage/data:<0x0>

There are few things you need to pay attention:

The pool seems working fine, otherwise you will see FAULTED instead of ONLINE:

state: ONLINE

The system has no problem to read/write the data. Doesn’t seem to be hardware problem:

NAME        STATE     READ WRITE CKSUM
        storage     ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0
            ada4    ONLINE       0     0     0
            ada5    ONLINE       0     0     0
            ada6    ONLINE       0     0     0
            ada7    ONLINE       0     0     0

This error message may give you some clue what’s wrong. Notice that storage and data are the pool names.

errors: Permanent errors have been detected in the following files:

        storage/data:<0x0>

The <0x0> represents the meta data of the pool. I think the problem may come from the upgrade process. Here are the steps how to solve this problem.

Force Clearing the Error

You can try to clear the error by running:

sudo zpool clear -F mypool

If it can clear the error, you are done. However, it is likely that it won’t work, and you need to move to the next step.

Scrubbing the Pool

You can try to scrub the entire pool by running:

sudo zpool scrub mypool

This will make the system to inspect every single block and correct the error. Although this process is long (It took 5 hours to inspect my 10TB pool), there is a very high chance that the problem will be corrected. Don’t forget to clear error after scrubbing the pool.

Making each devices online again

If the error still exists after scrubbing the entire pool (and clearing the error), you can try to force making each device go online:

sudo zpool online mypool /dev/ada0 /dev/ada2 /dev/ad4 ...

Try to reboot the computer

This is the last thing you can try. This will force the computer to mount the pool again. Hopefully it will clear the error and error status.

Rebuild the pool

If none of the method works, the only solution left is to rebuild the pool.

#Backup your data first
#sudo zpool destroy mypool
#sudo zpool create mypool ...

Good luck.

Our sponsors:

[FreeBSD]Problem to update PHP port

A new version of PHP (5.3.9) was available in FreeBSD today. Since it contained a lot of security fixes and enhancements, I decided to give it a try. After testing the new PHP in couple test servers, I think it is ready to upgrade the PHP on the production server. Oh well, I didn’t expect that I needed to spend my whole lunch break to trouble-shoot this problem. So here is what I did:

# cd /usr/ports/lang/php5
# make install
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for php5-5.3.9
===>  Extracting for php5-5.3.9
=> SHA256 Checksum mismatch for php-5.3.9.tar.bz2.
=> SHA256 Checksum OK for suhosin-patch-5.3.4-0.9.10.patch.gz.
===>  Refetch for 1 more times files: php-5.3.9.tar.bz2
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for php5-5.3.9
=> php-5.3.9.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://dk.php.net/distributions/.
fetch: http://dk.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://de.php.net/distributions/.
fetch: http://de.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://es.php.net/distributions/.
fetch: http://es.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://fi.php.net/distributions/.
fetch: http://fi.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://fr.php.net/distributions/.
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for php5-5.3.9
=> SHA256 Checksum mismatch for php-5.3.9.tar.bz2.
=> SHA256 Checksum OK for  suhosin-patch-5.3.9-0.9.10.patch.gz
===>  Giving up on fetching files: php-5.3.9.tar.bz2
Make sure the Makefile and distinfo file (/usr/ports/lang/php5/distinfo)
are up to date.  If you are absolutely sure you want to override this
check, type "make NO_CHECKSUM=yes [other args]".
*** Error code 1

Stop in /usr/ports/lang/php5.
*** Error code 1

Stop in /usr/ports/lang/php5.
*** Error code 1

Stop in /usr/ports/lang/php5.

Initially, I thought it was a checksum error. So I decided to skip the checksum, i.e.,

#make install NO_CHECKSUM=yes

Unfortunately, it gave the same error. I think the problem might come from corrupted port files or port database. Instead of finding the source of the problem, I decided to rebuild the whole thing.

First, let’s remove the port database:

#sudo rm -Rf /var/db/portsnap/*

Next, we need to re-download all port files:

#sudo portsnap fetch extract

Some new ports may be released during the extraction, let’s make sure that the port tree is up to date:

#sudo portsnap fetch update

Now, we need to manually download the php source. Make sure that the file is stored in /usr/ports/distfiles/

#cd /usr/ports/distfiles/
#sudo wget http://fi.php.net/distributions/php-5.3.9.tar.bz2

Now, try to test whether the system can build php again. Notice that this will not install the PHP in your system.

cd /usr/ports/lang/php5
sudo make

If it gives no error, which means the PHP is ready to go. Now let’s clean up our work and make sure everything is ready.

sudo make clean

Notice that there is no way to upgrade the PHP from Make without uninstall it. Since it is a production server, I want to keep the website running. So I decide to let Portmaster to do all dirty works for me.

sudo portmaster -Da

Depending on your CPU, it may take 5 minutes to an hour to finish the update. Normally, the standard php package will work fine after the update. However, if it is not a standard package, such as PECL, you will need to do one more step. For example, here is the error messages right after I upgraded PHP:

#php -v
[eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.3.8.
Rebuild it for your PHP version (5.3.9) or download precompiled binaries.

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/memcache.so' - /usr/local/lib/php/20090626/memcache.so: Undefined symbol "php_session_create_id" in Unknown on line 0

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/tokyo_tyrant.so' - /usr/local/lib/php/20090626/tokyo_tyrant.so: Undefined symbol "ps_globals" in Unknown on line 0

PHP 5.3.9 with Suhosin-Patch (cli) (built: Jan 12 2012 13:09:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

[eAccelerator] This build of “eAccelerator” was compiled for PHP version 5.3.8.
Rebuild it for your PHP version (5.3.9) or download precompiled binaries.

To solve this problem, simple rebuild the package, i.e.,

cd /usr/ports/www/eaccelerator
sudo make deinstall install clean

PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20090626/memcache.so’ – /usr/local/lib/php/20090626/memcache.so: Undefined symbol “php_session_create_id” in Unknown on line 0

#cd /usr/ports/databases/pecl-memcache
#sudo make deinstall
#sudo make install clean

PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20090626/tokyo_tyrant.so’ – /usr/local/lib/php/20090626/tokyo_tyrant.so: Undefined symbol “ps_globals” in Unknown on line 0

#cd /usr/ports/pecl-tokyo_tyrant
#sudo make deinstall
#sudo make install clean

After the re-installation is completed, make sure that PHP gives no complain:

#php -v

PHP 5.3.9 with Suhosin-Patch (cli) (built: Jan 12 2012 13:09:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

That’s it! Have fun.

Our sponsors: