# /scripts/perlmods -l | grep -ai "BSD::Resource"
not listed?
# /scripts/checkperlmodules --full
# /scripts/perlmods -l | grep -ai "BSD::Resource"
not listed?
# /scripts/checkperlmodules --full
cd /var/cpanel/users
for user in * ; do /usr/local/cpanel/bin/domain_keys_installer $user ; done
for user in * ; do /usr/local/cpanel/bin/spf_installer $user ; done
Error: Could not find functions file, your system may be broken
Fix:
touch /etc/rc.d/init.d/functions
/etc/rc.d/init.d/cpanel restart
You can disable the stats service (Analog Stats, Awstats or Webalizer) for a specific user by doing the following:
1) Login to your server via ssh.
2) Edit /var/cpanel/users/username, and add any of the following, as needed:
skipanalog=1
skipawstats=1
skipwebalizer=1
3) Now we’ll restart the cPanel service:
/etc/init.d/cpanel restart
The imagick.so PHP module can’t currently be installed via PECL, due to it’s inability to write to /var/tmp. To get around that, you can install it manuall:
# yum install ImageM* netpbm gd gd-* libjpeg libexif gcc coreutils make
# cd /usr/local/src
# wget http://pecl.php.net/get/imagick-2.2.2.tgz
# tar zxvf ./imagick-2.2.2.tgz
# cd imagick-2.2.2
# phpize
# ./configure
# make
# make test
# make install
This will compile imagick.so, and move it to your extensions directory specified in php.ini. Now you’ll need to add the following to php.ini:
extension=imagick.so
and restart apache:
/scripts/restartsrv_httpd
From time to time, strange issues pop up which aren’t going to be logged to an error log. For some of the more “hard to track down” issues, you can use strace to see just what the process is doing, and where your issue might be.
This article won’t go into how to read straces, as there are many other articles written about this, but I’ll provide a good base from which to start.
strace -v -o /root/strace.cpanel -f -s 4096 -p `cat /var/run/cpsrvd.pid`
That command uses several flags, outputting the strace to a file called strace.cpanel.
-v enables a more verbose output
-o specifies the file to output the contents to. If not specified, it will output directly to your terminal.
-f includes all processes forked by the process you’re stracing
-p will specify the PID. In this case, we’re going to cat the pic from cpsrvd.pid
Quotas can be kind of a pain sometimes. If your accounts are showing 0 disk space used, be sure that you have enabled quotas in cPanel. Most people select this option during the initial cPanel configuration, but you can always enabled them later in WHM -> Initial Quota Setup. Once you’ve done that, let’s ensure that quotas are enabled on your partitions. You really only need them enabled on /home and /var. If you have a single partition, enable them on /.

If you needed to add usrquota to your /home partition, save your changes in /etc/fstab, and remount /home with
mount -o remount /home
Now we can run the following to repair the quotas:
/scripts/fixquotas
There are still plenty more ways that quotas can break, and dozens of errors associated with broken quotas, which I hope to go into deeper in the future.
From http://forums.cpanel.net/f43/account-based-email-login-problem-97109.html
root@servername [/home]# authtest -s imap test@normaldomain.info password
Authentication succeeded.
Authenticated: test@normaldomain.info (system username: normaldo)
Home Directory: /home/normaldo/mail/normaldomain.info/test
Maildir: /home/normaldo/mail/normaldomain.info/test
Quota: 262144000S
Encrypted Password: $1$KHntyoqN$wih5o0N7ZTf6Fm4vasrxj.
Cleartext Password: password
Options: (none)
FOR MY PROBLEMATIC DOMAIN:::
root@servername [/home]# authtest -s imap info@problemdomain.info password
Authentication FAILED: Operation not permitted
What you want to do next is check /usr/local/cpanel/logs/login_log to see what the exact issue is. In my circumstance, I received this error:
208.74.121.102 - info@jurnamakelaars.nl [10/04/2009:14:37:11 -0000] "POST /login/ HTTP/1.1" FAILED LOGIN webmaild: user password hash is missing from system (user probably does not exist)
I then checked the user’s shadow file in /home/USERNAME/etc/domain.com/shadow and saw that it was corrupt. I removed the file, created a new one, and applied user:mail permissions. I then created a new email account, then copied the user’s encrypted password after making entries in shadow for the existing users. I was then able to login to each webmail account without issue.
If using x3, edit the following file:
/usr/local/cpanel/base/frontend/x3/mail/popsinclude.html
and modify
input type="text" name="quota" value="250"
Change the value from 250 to your new default. This will modify the default quota server-wide.
There are a few avenues of support outside of cPanel Technical Support, where you can ask other cPanel Administrators for support:
1. Forums – http://forums.cpanel.net
2. IRC – On EFNET, join #cpanel