When compiling php from source, some CentOS 64 bit users have reported getting an error like this:

/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status

Now, this error can be triggered in a couple different places and if you do a general Google search you’ll get all kinds of advice about installing this or that module. All great advice, but not your solution. Here’s what you need to do:

1. Verify that the libtool and libtool-ltdl packages are installed.
2. Symlink libltdl.so to libltdl.so.x.x.x

Step one is easy.

[root@fe01 ~]# yum install libtool-ltdl.x86_64 libtool.x86_64

yum list |grep libtool |grep installed

libtool-ltdl.x86_64                      1.5.22-6.1             installed
libtool-ltdl-devel.x86_64                1.5.22-6.1             installed

However, note that if you have libtool already installed, if you ‘yum info libtool*,’ yum wont list any of the related packages. I don’t know why this is or how to fix it (or if you even want it fixed) — I simply didn’t investigate. Just know that you’ll have to manually execute the aforementioned statement. The ‘.x86_64′ might be redundant if libtool has already been installed. Make sure to install libtool-ltdl though!

Step two took me a while to figure out. Apparently PHP looks for the libltdl library only at (for x64 at least) /usr/lib64/libltdl.so. The symlink to this file is not included in the libtool packages (for what reason I don’t know — but apparently this has been true and been stumping people since early 2006[1]) so you’ll have to make it yourself. Execute:

[root@fe01 ~]# cd /usr/lib64
[root@fe01 lib64]# ln -s libltdl.so.3.1.4 libltdl.so

And that’s it. PHP should configure and compile without error. Well, without this particular error at least.

I hope the time you save reading this will make up for my wasted evening.

Just in case i need to remember them at some point

/usr/sbin/exim -v -Mrm (MAIL ID HERE) ==> REMOVE MAILS BY ID

exim -bpr | grep frozen | wc -l ==> How many Frozen mails on the queue

Some users may experience problems when uploading large files via a webpage. The resultant errors often look like this:

Request body is larger than the configured limit (134217728).

This is because the request body’s default maximum size is set lower than the size that was submitted. A detailed explanation of how and why this directive is used can be found here: http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody

To work around the issue create a .htaccess file in the same directory as the page causing the issue. Insert one of the following lines:

LimitRequestBody 0 ## unlimited up to 2GB
LimitRequestBody 2097152 ## 2 MB, decent default for many cases.

and save this file. If you increased the size correctly the page should now be working.

IndexOptions
IndexOptions controls the appearance of server generated directing listings, by adding icons, file descriptions, and so on. If Options Indexes is set, the Web server generates a directory listing when the Web server receives an HTTP request for a directory without an index.

First, the Web server looks in the requested directory for a file matching the names isted in the DirectoryIndex directive (usually, index.html). If an index.html file is not found, Apache HTTP Server creates an HTML directory listing of the requested directory. The appearance of this directory listing is controlled, in part, by the IndexOptions directive.

FancyIndexing
This means that a user can re-sort a directory listing by clicking on column headers. Another click on the same header will switch from ascending to descending order. FancyIndexing also shows different icons for different files, based upon file extensions.

The default configuration on a cPanel powered server turns off FancyIndexing. To enable this feature, do the following:

1. Makse sure the file httpd-autoindex.conf exists in /etc/httpd/conf/extra directory
2. Add the following directives to your /etc/httpd/conf/httpd.conf file:
   <IfModule mod_autoindex.c>
   IndexOptions FancyIndexing IconHeight=16 IconWidth=16
   </ifModule>
3. Run this command to restart httpd:
   • /scripts/restartsrv httpd

error while loading shared libraries: libavdevice.so.52: cannot open shared object file: No such file or directory

right, this error usually comes when ldconfig does not know where to search for the libraries, so, in order to help it out,  on my fedora/centos systems, i did the following:

cd /etc/ld.so.conf.d

add another file:  custom-libs.conf

inside, put :

/usr/local/lib

save,

then do ldconfig, et voila.

Enjoy

The following error is displayed:

configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL
is present. This should not happen. Check config.log for additional
information.

Expected result:
----------------
should configure without any errors.

Actual result:
--------------
In config.log the last 5 lines are:

configure:45747: checking if your cpp allows macro usage in include
lines
configure:45759: gcc -c -I/usr/include -g -O2  conftest.c 1>&5
configure:46103: checking for IMAP support
configure:46149: checking for IMAP Kerberos support
configure:46174: checking for IMAP SSL support
configure:46590: checking for utf8_mime2text signature
configure:46608: gcc -c -I/usr/local/imap-2006j/include  conftest.c
1>&5
configure:46637: checking for U8T_CANONICAL
configure:46653: gcc -c -I/usr/local/imap-2006j/include  conftest.c

For this you need some packages installed:

if it's a 64 bit system, as mine,

yum install pam-devel -y
yum install cyrus-imapd-devel.x86_64 -y
yum install libc-client-devel.x86_64 -y
yum install libc-client-devel.i386 -y

this should help fixing. if it's 32 bit system , just take the same rpms and install via yum

When you’re compiling apache 2.2 and upper versions, on 64 bit architectures, Fedora, Centos whatever, while running make will result in this error :

libexpat.so: could not read symbols: File in wrong format

If you got this, it’s simple: you’re compiling 32 bit native apache on 64 bit architecture, so it has issues finding the lib folder.

FIX: add the following 2 lines below to the ‘./configure’ line, then rerun ‘make’.

–enable-lib64
–libdir=/usr/lib64

On servers that are running the perl modules that are a part of PathTools, MailScanner breaks with the recently released v3.26. If you’re suffering from this issue you’ll see MailScanner continually restarting. If you run MailScanner in –debug you’ll see it SegFault. In /var/log/messages you’ll see continual:

MailScanner: Process did not exit cleanly, returned 0 with signal 11

You can confirm which version of PathTools is installed using:

perl -MCwd -e ‘print “$Cwd::VERSION\n”‘

To fix this you need to downgrade PathTools to v3.2501:

wget http://search.cpan.org/CPAN/authors/id/K/KW/KWILLIAMS/PathTools-3.2501.tar.gz
tar -xzf PathTools-3.2501.tar.gz
cd PathTools-3.2501
perl Makefile.PL
make
make install
cd ..
rm -Rfv PathTools-3.2501*

A frequent error message received when using the mysql command line utility is: Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ While this error message can be frustrating, the solution is simple.

When connecting to a MySQL server located on the local system, the mysql client connects thorugh a local file called a socket instead of connecting to the localhost loopback address 127.0.0.1. For the mysql client, the default location of this socket file is /tmp/mysql.sock. However, for a variety of reasons, many MySQL installations place this socket file somewhere else like /var/lib/mysql/mysql.sock.

While it is possible to make this work by specifying the socket file directly in the mysql client command

mysql –socket=/var/lib/mysql/mysql.sock …

it is painful to type this in every time. If you must do so this way (because you don’t have permissions to the file in the solution below), you could create an alias in your shell to make this work (like alias mysql=”mysql –socket=/var/lib/mysql/mysql.sock” depending on your shell).

To make your life easier, you can make a simple change to the MySQL configuration file /etc/my.cnf that will permanently set the socket file used by the mysql client. After making a backup copy of /etc/my.cnf, open it in your favorite editor. The file is divided into sections such as

[mysqld]
datadir=/usr/local/mysql/data
socket=/var/lib/mysql/mysql.sock

[mysql.server]
user=mysql
basedir=/usr/local/mysql
If there is not currently a section called [client], add one at the bottom of the file and copy the socket= line under the [mysqld] section such as:

[client]
socket=/var/lib/mysql/mysql.sock

If there is already a [client] section in the my.cnf file, add or edit the socket line as appropriate. You won’t need to restart your server or any other processes. Subsequent uses of the mysql client will use the proper socket file.

Extrapolating this to my case, i moved the MySQL database to another hard-drive, so the client would still connect to the old .sock file, so i defined the CLIENT section in /etc/my.cnf.

Also, i had to change in php.ini the default mysql_connect socket, to point to the new location.

In case you’re using MailScanner, it has to be restarted as well, because it will still try to use the old mysql socket.

Fetching 4115 new ports or files… /usr/sbin/portsnap: cannot open a933dd1da50d053b997b5626a889cec90a86ed5dfc82135c7a975a46d78dce02.gz: No such file or directory
snapshot is corrupt.

if by any chance you get this error, on FreeBSD, while updating the ports with portsnap, do the following:

cd /var/db/portsnap

rm -rf *

portsnap fetch extract

It will work.