checking for utf8_mime2text signature

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

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

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

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

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 https://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*

Can’t connect to local MySQL server through socket /tmp/mysql.sock

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.

/usr/sbin/portsnap: cannot open snapshot is corrupt

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.

could not open default font ‘fixed’

This error usually happens due to POOR coding of the software,
and this goes with a big boo to realvnc. Just bought
the license last night. So it seems the new paths of X are
different, so we are just going to make a nice symlink:
[root@jupiter ~]# vncserver
  VNC Server Enterprise Edition E4.3.1 - built Aug 14 2007 14:54:48
  Copyright (C) 2002-2007 RealVNC Ltd.
  See https://www.realvnc.com for information on VNC.
  Couldn't open RGB_DB '/usr/X11R6/lib/X11/rgb'

  Xvnc Enterprise Edition E4.3.1 - built Aug 14 2007 14:58:37
  Copyright (C) 2002-2007 RealVNC Ltd.
  See https://www.realvnc.com for information on VNC.
  Underlying X server release 40300000, The XFree86 Project, Inc

  Sun Oct 21 19:15:01 2007
   vncext:      VNC extension running!
   vncext:      created VNC server for screen 0
   TcpListener: listening on IPv4, port 5901
   TcpListener: listening on IPv4, port 5801
  error opening security policy file
/usr/X11R6/lib/X11/xserver/SecurityPolicy
  Could not init font path element /usr/X11R6/lib/X11/fonts/misc/, removing
from list!
  Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/,
removing from list!
  Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing
from list!
  Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing
from list!
  Could not init font path element /usr/X11R6/lib/X11/fonts/75dpi/, removing
from list!
  Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/,
removing from list!

  Fatal server error:
  could not open default font 'fixed'

Do the thing down here, and poof ! it works.

ln -s /usr/share/X11 /usr/X11R6/lib
Enjoy. Waiting for feedbaaaack

DomainKeys on cPanel how to

I found on the cPanel forum that DomainKeys was already installed in the version of cPanel I have on my server.

Apparently, with my setup, all I needed to do was to install it and make sure that the DNS was set up correctly. This was done by logging into my server and typing:

/usr/local/cpanel/bin/domain_keys_installer <user name>

Where <User name> was the name of the user for the zone that I wanted DomainKeys set up for.

The installer made an entry in the DNS for the particular zone.

I use an external DNS service and so I had to copy the entry that was made automatically to my DNS service.

This was  the default._domainkey entry… So in my eternal DNS service I created a TXT entry named default._domainkey and copied and pasted the value that the installer had created.

I also created another entry:

_domainkey “t=y; o=-”

The only thing left to do was test the setup. I sent an e-mail from my server to a Yahoo account and Yahoo deemed that I had an acceptable DomainKey.

I also sent an e-mail to: check-auth@verifier.port25.com

which also replied with positive results.

I found that a lot of tester out there gave negative results, but I am assuming that the testers were not up to date with the latest DomainKeys standard.

Cannot install/update Click Be!/Fantastico/Universina?

If you have Fedora Core 5/6 or CentOS 5 or Red Hat Enterprise Linux 5 on your server and are experiencing troubles with respect to upgrades (forced or
otherwise) of Click Be! or Fantastico or Universina, please check the wget version that you have on your server.

If it is wget-1.10.2-3.3.fc5 or wget-1.10.2-7.el5 or wget-1.10.2-8.fc6.1, we suggest that you replace it immediately with an older and/or stabler
version. This version does not honor the “-P” switch.

An alternate version that we suggest is wget-1.10.2-3.2.1

You can use the following commands for this purpose:
Code:

rpm -qa wget ;
wget https://fedora.osmirror.nl/core/development/i386/Fedora/RPMS/wget-1.10.2-3.2.1.i386.rpm ;
rpm -e wget ;
rpm -ivh –force wget-1.10.2-3.2.1.i386.rpm ;
rpm -qa wget ;

Note: You must execute the commands shown above as root.

Reports suggest that the version of wget included with Fedora Core 7 does not have this problem, so that may be a better option for some people.