Saturday, September 11, 2010

How to build and install Postfix on 64 Bit CentOS or RedHat

How to build latest postfix from source with MySQL and PCRE support on
64 bit Linux (CentOS or RHEL)

First make sure you have Mysql and pcre libraries installed, in not, then install them

#yum install mysql-devel pcre-devel

Then download the latest source for Postfix, cd into the Postix directory,
it should have several fines, and MUST have Makefile.init

From this directory type:

make -f Makefile.init makefiles \
'CCARGS=-DHAS_MYSQL -I/usr/include/mysql -DHAS_PCRE -I/usr/include' \
'AUXLIBS=-L/usr/lib64/mysql -lmysqlclient -lz -lm -L/usr/lib64 -lpcre'

Then type make
then "make install"

if will ask several questions, just accept defaults by hitting "Enter"
This is it

Now stop and restart your sendmail
/etc/rc.d/init.d/sendmail stop
/etc/rc.d/init.d/sendmail start

Now check to make sure that mysql and pcre are on the list
of supported posfix maps:

type: /usr/sbin/postconf -m

You should see mysql and pcre in the list of maps

Of cause make sure to properly edit the configuration files
in the /etc/postfix directory.

That's a whole new big article (more like a small book), so I am not going to explain about postix
configuration here.

Friday, September 10, 2010

php 5.3.3 skipping incompatible /usr/lib/mysql/libmysqlclient.so

If you having problem building php 5.3 on 64 bit Linux and getting some errors about
skipping incompatible /usr/lib/mysql/libmysqlclient.so when searching for -lmysqlclient

You just need to specify the correct path to where the 64bit libs are for mysql

Do this before running ./configure:

export LDFLAGS=-L/usr/lib64/mysql

Sunday, August 29, 2010

Php suddenly died, no error messages


A very nasty error occurs in php is you declare the same instance variable more than once
in the same class (you know, if the beginning of the class file)
or for that matter the method with the same name is declared twice in the same class

This is an easy mistake to make, but it causes the php to die with very little
error. In fact, depending on your error reporting level you may never even see
any errors in the error log, no errors on the screen, nada!

All you will see is that suddenly your script is dead. I mean completely dead, objects
not even instantiating.

This is nasty, so watch our for that!

Saturday, August 28, 2010

How to make php DOMDocument Serializable

The default DOMDocument class in php is not serializable.
That is, if you run $myDOM = serialize($oDOM), then unserialize($myDOM)
you will get back the object of type DOMDocument, but the data
will be lost, so you will basically get back the empty DOM Document,
not even the root element will be there, nada!

But it's easy to fix that. All you have to do is
extend the DOMDocument and implement Serializable interface

This is how you do it:

class MyDOMDocument extends DOMDocument implements Serializable
{

public function __construct(){

parent::__construct();

}

public function serialize(){
$s = $this->saveXML();
return $s;
}

public function unserialize($serialized)
{
$this->loadXML($serialized);

}
}

Ok, now if you serialize() and then unserialize() you will get back
the object of type MyDOMDocument and it will have the same data
as it had before serialization.

Of cause this will only work with PHP 5.2 or better and SPL libraries enabled (they are by default in php5)

Friday, August 27, 2010

Weird stuff with ArrayObject after exchangeArray()

OK so if you have extended php ArrayObject

then set extra property in object,
then exchangeArray() with new array

What happends to that extra property?
Right now it looks like that property is gone, which is odd
because only the internal array should be changed but it looks
like as if the whole object has been recreated.

Interesting to know. I must do an experiment and
get a definitive answer.

Monday, August 9, 2010

Common mistake that prevents Google from using your sitemap.xml file

According to official specification from sitemaps.org
(here: http://sitemaps.org/protocol.php#lastmoddef )
the format of the lastmod element in sitemaps file should be in the W3C Datetime format
but the actual time can be omitted.

One common mistake people make when generating sitemap file is to make the lastmod value in a format like this: YYYY-DD-MM HH:MM:SS
This is a wrong format and will not be understood by Google.
The correct W3C timestamp format is quite ugly, and looks like this:
(example) 1997-07-16T19:20:30.45+01:00

The best advice I can give you is to remove the HH:MM:SS and only leave the date part of the datetime, like this for example: 2010-03-23

This format is understood by all search engines and will not cause any problems.

Tuesday, July 6, 2010

How to get LogCat view pane in Eclipse Android SDK

In Eclipse with Android SDK installed:

Window > Show View > Other
Then expand Android and then select LogCat
You may also select other useful Views like Threads and Emulator Controls