This error has been observed mostly on BSD servers even on brand new installs .
It is even that the IMAP server under Courier is not starting at all or the Authentication daemon is throwing out errors.
One of the errors can be seen when trying to access Squirrelmail or Horde, it is even you can not login or get an error like:
Warning: fsockopen() [function.fsockopen]: unable to connect to localhost:143 (Connection refused) in /usr/local/cpanel/base/3rdparty/squirrelmail/plugins/login_auth/functions.php on line 129
If you use the Current version of Cpanel you may want to check firstly if IMAP is actually set to Start or not.
You can check this under WHM >> Service Configuration >> IMAP Coonfiguration .
Under cPanel 11.24.x it is now called Mailserver Configuration .
If this is set to On and you still have issues then try and check the
/etc/rc.conf file(FreeBSD) .
Regarding IMAP and the authentication daemon you should see the following lines in there:
If you do not see any of this lines or any of them is looking different edit
/etc/rc.conf and edit the line to look like the ones i’ve posted.
In the last weeks seems that some particular error showed up more often on servers that are running Fatastico under Cpanel.
The error itself looks like this:
Fantastico is not installed at the default location /usr/local/cpanel/3rdparty/fantastico. Either move the Fantastico directory from it's current location to /usr/local/cpanel/3rdparty/fantastico OR enable ioncube loaders in WHM -> Tweak settings.
I am not sure of the cause of the error but seems to be related to the PhP compiling options for CPanel(this is not the same with PhP running under Apache) .
Enabling IonCube seems to not resolve this issue.
Anyway a simple fix to this problem is to recompile the PhP for CPanel and not this is not being done by using EasyApache but by running the following:
/scripts/makecpphp – This will recompile the php that is serving Cpanel
Like i said the two php versions and compile options are not the same for Cpanel and Apache on a Cpanel server.
Had a few clients lately blocking them self out and when i say blocking i mean blocking the user root because of them inserting the wrong password more then X times when Brute Force Protection was enabled on the server.
Of course that they were unable to login anymore to the server using the root user and more to it no one was able to login over an ssh connection.
A way around this is to access the server in single user and delete the blocked users:
mysql> delete from brutes;
mysql> delete from logins;
Now this happens usually if the following setting is set to low when setting up Brute Force Protection:
Maximum Failures By Account:
For anyone who has this kind of issues you may want to create a second user on the server and add that user to the
sudoers /etc/sudoers group so that if you block the root user out you will still be able to access the server and fix the problem.
All this goes also for anyone who uses another user to connect to the server and has root ssh access disabled.