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.
Saturday, September 11, 2010
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
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)
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.
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.
(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
Window > Show View > Other
Then expand Android and then select LogCat
You may also select other useful Views like Threads and Emulator Controls
Subscribe to:
Posts (Atom)