Category: Technology

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

Posted on by

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:

[Adobe Lightroom / Photomatix]Lightroom rendition failed

Posted on by

Yesterday, I was processing some of the pictures in Adobe Lightroom. I liked to export few of them to Photomatix for HDR processing. Then, the system complained with this error message:

Lightroom rendition failed

After searching this error message on Google, I found that this message was generated by the Photomatix plug-in. According to Photomatix’s FAQ, it seems that the original picture is missing.

So, I ran a quick test (Find Missing Photos) in Adobe Lightroom, and of course it didn’t find anything. After some investigations, I found that the problem was caused by low free space in harddrive.

It is very easy to solve this problem. Simply change the Windows temporary drive to somewhere else and you are done.

So what cause this problem? When you export the pictures to other applications, Lightroom will first convert them in some common format first (usually TIFF), such that the other applications will be able to read the files. During this process, Lightroom will store these pictures in the temporary directory provided by Windows, and this settings cannot be changed within Lightroom.

By default, the temporary directory is in the system drive (e.g., C:). If you are using SSD harddrive, you may have very limited amount of free space left. Therefore, it is a good idea to assign the temporary directory to another drive with more space.

Here are the step by step tutorial:

  1. Start
  2. Control Panel
  3. System
  4. Advanced system settings
  5. Environment Variables

Now we are ready to change the location of temporary directory. Let’s edit the TEMP and TMP, and change them to something else. In my case, I have more space in d:, so I set them to D:\Temp.

Click OK and save. Now, restart your Lightroom and the error message will be gone.

–Derrick

Our sponsors:

[PHP]How to delete Memcache variables in PHP?

Posted on by

I’ve never thought about deleting a Memcache key is a difficult task. It took me few hours to figure out a working solution. No kidding. FYI, I am using PHP 5.4

Suppose you store a very expensive data into the Memcache, and you decide to delete it later. According to the PHP documentation, it should be very simple:

$memcache_obj->delete('key_to_delete');

or

memcache_delete($memcache_obj, 'key_to_delete');

However, this method only works with scalar variables, such as string, integer, double, float, Boolean etc. It does not work with non-scalar variables such as array, object etc.

I have tried many different ways, such as setting the value to something else, e.g., 

$memcache->set('key_to_delete', 'deleted');

or making the key to expire immediately:

$memcache->set('key_to_delete', 'deleted', 0, 1);
$memcache->set('key_to_delete', 'deleted', 0, -1);

Unfortunately, none of these methods worked in my case (my variable is a non-scalar array). So, I ended up doing it in a low-level way: Bypassing the PECL-Memcache (PHP Library) and talk to the Memcache server directly. Guess what, it works very well. The variable gets deleted!

function MEMCACHE_DEL_HASH($key){
	
	if ($key == '') return FALSE;
	
	$socket = @fsockopen('localhost', 11211);
	$command = "delete {$key}";
	
	fwrite($socket, $command."\r\n");
	fclose($socket);
	
	return true;
}

And it is super easy to call this function:

MEMCACHE_DEL_HASH('key_to_delete');

Feel free to modify this function such that you can pass in the connector, port or do anything you like.

That’s it! Have fun with Memcache.

–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

Posted on by

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

Posted on by

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

Posted on by

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:

[PHP]Fatal error: Allowed memory size of x bytes exhausted (tried to allocate y bytes)

Posted on by

A user complained to me that my PHP web applications stopped working today. After I digged into the error log, I found that following message:

PHP Fatal error:  Allowed memory size of 262144 bytes exhausted (tried to allocate 261900 bytes) in Unknown on line 0

Obviously, this is related to the memory error. Therefore I tried to increase the limit of memory_limit in php.ini. Since I have 8G of memory in my box, I think it is okay to set the memory limit of PHP to 4GB.

;memory_limit = 128M
memory_limit = 4096M

When I restart the Apache/PHP, I found another nightmare. My web application stopped working! When the user tries to access http://mywebsite/index.php, instead of rendering the code, the browser kept prompting the user to download the file.

After scratching my head for a while, I found that I missed something, which is very very important. I was running XAMPP (32-bit) on a Fedora 64-bit machine. See the problem? Since XAMPP is running in 32-bit, it does not understand what is 4096 MB. (If you install 4GB of memory in any Windows 32-bit machine, you will notice that Windows can only allocate 3GB of them, and the 1GB left memory is sitting inside your computer and doing nothing…) Therefore, I decrease the memory_limit to 2048MB, and that solved the problem.

Time to move away from XAMPP.

–Derrick

Our sponsors:

[Solved]Problem to Update OpenLDAP in FreeBSD

Posted on by

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

Posted on by

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:

How to Install a 2.5TB, 3TB drives on Linux

Posted on by

Recently I got a new hard drive (3TB) for my Linux box at work. I didn’t realize that it is problematic / nightmare to do such a simple work.

First, if you try to use fdisk to add the drive, it won’t work. Or I should say… it works, but it only give you a 2TB usable space. This is a limitation of fdisk, because it can handle up to 2^32 -1 sectors (or 2TB). That’s why fdisk is not a solution here.

It seems that the only solution is using parted.

sudo parted /dev/sdd

It will return something like this:

GNU Parted 2.3
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)

First, we want to create a label:

(parted) mklabel gpt
Warning: The existing disk label on /dev/sdd will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes

Then, we want to specify the unit:

(parted) unit TB

And tell parted to use all available space:

(parted) mkpart primary 0 -0

Next, we need to review the summary:

(parted) print
Model: ATA WDC WD30EZRX-00M (scsi)
Disk /dev/sdd: 3.00TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      0.00TB  3.00TB  3.00TB  ext2         primary

As you can see, the size is 3TB. Don’t worry about the file system for now (ext2). If it looks good to you, now we need to leave parted.

(parted) quit
Information: You may need to update /etc/fstab.

Next, we need to format the partition:

#CentOS 6
sudo mkfs.ext4 /dev/sdd1

#CentOS 7
sudo mkfs.xfs /dev/sdd1

After few seconds, it will give you some more information about your drive:

mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=1 blocks, Stripe width=1 blocks
183148544 inodes, 732566272 blocks
36628313 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
22357 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Now you can use your drive, such as mounting or putting it into /etc/fstab

sudo mount /dev/sdd1 /mnt/
df
/dev/sdd1             2.8T   42G  2.6T   2% /mnt

That’s it! Enjoy your new disk.

–Derrick

Our sponsors: