WHM – cPanel

whm-cpanel sorunları

Mod Security Error: Access denied for user ‘modsec’


Eğer sizde cpanel sunucularınızda Mod Security kısmına erişmek istediğiniz zaman aşağıdaki hata mesajını alıyorsanız yapmanız gereke oldukça basit.

‘The mod_security plugin could not connect to the database. Please verify that MySQL is running. Error: Access denied for user ‘modsec’@’localhost’ (using password: YES)’

SSH komut satırınından sırasıyla aşağıdaki komutları çalıştırmanız yeterli

1.  Bu komutu çalıştırarak #dbpassword karşısındaki şifreyi alın.

nano /etc/cron.hourly/modsecparse.pl

2. mysql mysql

3. update user set Password=password('PASSWORDHERE') where User='modsec';

4. flush privileges;

5. quit;


Centos xpdf,libXp ve antiword kurulumu


cd /usr/local/src/

Dowload following RPM’s files under the /usr/local/src/ directrory.

wget http://mit.edu/zacheiss/dev/rhlinux/redhat-7.1-updates/SRPMS/xpdf-0.92-4.71.0.src.rpm

wget ftp://ftp.univie.ac.at/systems/linux/fedora/core/6/i386/os/Fedora/RPMS/libXp-1.0.0-8.i386.rpm

wget http://dag.wieers.com/rpm/packages/antiword/antiword-0.37-3.el5.rf.i386.rpm




rpm -ivh xpdf-0.92-4.71.0.src.rpm

rpm -ivh libXp-1.0.0-8.i386.rpm

rpm -ivh antiword-0.37-3.el5.rf.i386.rpm

Then you can check it

root@server [/usr/local/src]# which xpdf
root@server [/usr/local/src]# which antiword

cPanel Log file locations


cPanel log file locations and Basic troubleshooting, most activity that happens on a server to log files, so that you can go back and review log entries for problems, instead of having to be on the server at the time of them happening.


Kernel Boot & Hardware error logs

Path : /var/log/dmesg

Use the command ” dmesg ” in the root shell to display all the kernel ring buffer (last 64 K) stored in the memory. Just use ” dmesg > boot.messages ” to store the logs in the separate file, and if you want to clear the dmesg just type ” dmesg -c “.


System Informations

Path : /var/log/messages

Use “ tail -f /var/log/message ” to list what is going on with your system and with your dns. This logs helps the admin to find our any form of tcp/udp and other form of attacks.

Bad Login / Logout logs

Path : /var/log/btmp

Stores all the bad login and logout attempts either failure or success. Just use the lastb command to list all the log in a clear format with date/time etc to trace and block the attack source. This kind of attacks on ssh are normally done using a script with Brute force password crackers.

Login / Logout logs

Path : /var/log/wtmp

Similar to the bad login/logout this log store the good/authorized system login and logout which can be listed using ” last “  command.

Last Logins Logs

Path : /var/log/lastlog

Database times of previous user logins. The lastlog file is a database which contains info on the last login of each user. Use the ” lastlog ” command to retrieve the data from the logs.

Authentication logs

Path : /var/log/secure

Logs all daemons which requires PAM Authentication.

Common Cpanel logs

cPanel/WHM Initial Installation Errors

Path : /var/log/cpanel*install*

Logs use to record the missing dependency or any error which its encouter during the cpanel installation process including the hardware driver failures/mis-matches.

Cpanel License Error Logs

Path : /usr/local/cpanel/logs/license_log

License and its updated information’s are stored here, if you are encountering with any license issue just execute the command /usr/local/cpanel/cpkeyclt to update the license from the cpanel.

Cpanel/WHM Accounting Logs

Path : /var/cpanel/accounting.log

Contains a list of accounting functions performed through WHM, including account removal and creation. So the administrator can make of this logs to check who deleted the account and from which ip etc.

Cpanel/WHM Service Status Logs

Path : /var/log/chkservd.log

Separate logs for the cpanel’s chkservd daemon which logs the service failure and notifications.

Cpanel Stats Daemon Logs

Path : /usr/local/cpanel/logs/stats_log

The stats daemon (cpanellogd) logs the output from all stats generators (Awstats, Webalizer, Analog) here.

Cpanel login and access logs

Path : /usr/local/cpanel/logs/access_log

All the login attempts and logins will be logged in this logs which helps the administrator to check who logged in to the panel on which time/ip address etc.

Cpanel Bandwidth Logs

Path : /var/cpanel/bandwidth

Files contain a list of the bandwidth history for each account. Each named after their respective user.

Tailwatchd Daemon logs

Path : /usr/local/cpanel/logs/tailwatchd_log

Logs for daemon configured under tailwatchd ie. cPBandwd, Eximstats, Antirelayd.

Cpanel Ftp logs

Ftp General login and Failure

Path : /var/log/messages

FTP Data Transactions log

Path : /var/log/xferlog

Is a symbolic link in most cases to /usr/local/apache/domlogs/ftpxferlog, which contains a history of the transactions made by FTP users.

FTP account Raw logs.

Path : /usr/local/apache/domlogs/ftp.domainname-ftp_log

Store all the ftp login/transfers ftp commands, client connection status etc.

Pure-ftp log

Path : /var/log/pureftpd.log

It will be disabled by default and only works if you enable it in the /etc/pure-ftpd.conf .

Pro-ftp log

Path : /var/log/pro-ftpd.log

It will be disabled by default and only works if you enable it in the /etc/pro-ftpd.conf

Cpanel Mysql logs

MySQL General Information and Errors

Path : /var/lib/mysql/$(hostname).err

This path could vary, but is generally located in /var/lib/mysql. Could also be located at /var/log/mysqld.log.

Cpanel Apache logs

Apache Access Logs:

Path : /usr/local/apache/logs/access_log

Complete web server access log records all requests processed by the server.

General Error and Auditing Logs

Path : /usr/local/apache/logs/error_log

All exceptions caught by httpd along with standard error output from CGI applications are logged here, including apache crash etc.

Apache SuExec Logs

Path : /usr/local/apache/logs/suexec_log

Auditing information reported by suexec each time a CGI application is executed. Useful for debugging internal server errors, with no relevant information being reported to the Apache error_log, check here for potential suexec policy violations.

Domain Access & error logs

Path : /usr/local/apache/domlogs/domain.com

General access and error log file for each domain configured with cPanel.

Cpanel Exim logs

Mail Receive and Delivery

Path : /var/log/exim_mainlog or /var/log/exim/mainlog(FreeBSD)

Receives an entry every time a message is received or delivered.

ACLs/Policies based RejectLog

Path : /var/log/exim_rejectlog

An entry is written to this log every time a message is rejected based on either ACLs or other policies eg: aliases configured to :fail

Panic/Fatal Errors :

Path : /var/log/exim_paniclog

Logs any entries exim doesn’t know how to handle. It’s generally a really bad thing when log entries are being written here, and they should be properly investigated


Path : /var/log/maillog & /var/log/messages

The IMAP, POP, and SpamAssassin services all log here. This includes all general logging information (login attempts, transactions, spam scoring), along with fatal errors.

SSH ile MySQL Yedeği Alma ve Geri Yükleme


SSH ile MySQL Yedeği Alma ve Geri Yükleme işlemini yapmak oldukça basit.

Öncelikle konsolumuza bağlı olmamız gerekiyor. Daha sonra aşağıdaki komutları n birincisi yedek almak için. İkincisi ise alınan mysql yedeği eri yüklemek için kullanıyoruz.

mysqldump -u veritabaniadi -p kullaniciadi > emiryeniyedek.sql
mysql -u veritabaniadi -p kullaniciadi < emiryeniyedek.sql

cPanel PHP Ayarları



Most PHP options enable an extension that is shipped with PHP. Other PHP options change how PHP is served.

PHP Options

The following options affect on how PHP is served:

CGI This option is enabled by default. If you disable this option, a PHP CLI binary will be installed in both the /usr/bin/php and/usr/local/bin/php directories. When no CGI binary is available, your server will be unable to serve PHP requests without DSO.
DiscardPath This security option is provided by PHP, but we do not recommend it. If you enable this module, PHP will be unable to function with CGI or FCGID. However, DSO and SuPHP will be able to serve PHP.
FastCGI This option is one way to serve PHP. If you wish to use FastCGI, you must compile Apache with mod_fcgid support and PHP with FastCGI support. FastCGI may interfere with how PHP is served through CGI and suPHP. We recommend that you only enable this option if you will run PHP through mod_fcgid and understand that you must tune FasctCGI's performance.
ForceCGIRedirect This security option is provided by PHP. If you enable this option, PHP will have compatibility issues with CGI.
SafePHPCGI This option sets two flags for PHP that attempt to lock PHP to system php.ini files. This prevents users from the ability to use custom php.ini files when PHP is served through CGI. However, if you enable this option, you can use custom php.ini files if you run PHP with mod_suphp.
Versioning This option was intended to allow the same functionality as concurrent DSO patches; however, it does not work well and is not recommended by cPanel or PHP.

Cpanel Exim mail kuruğunu silme


Cpanel exim üzerinde mail kuruğunu silmek isterseniz aşağıdaki iki satır size yetecektir.

# cd /var/spool/exim/input/
# rm -rf *

6963 File size limit exceeded/usr/sbin/exim -bd -q1h


Eğer sizde linux cpanel üzerinde mail, exim servisinde bu hatayı alıyorsanız yapmanız gereken işlemler aşağıdaki gibi.

Bu hatanın sebebi log dosyasını 2gb ye ulaşmış olması.  /var/log/exim_mainlog — 2GB

# ls -lh /var/log/exim_mainlog

# mv /var/log/exim_mainlog /var/log/exim_mainlog.BAK.$(date +%F)
# touch /var/log/exim_mainlog
# chown mailnull.mail /var/log/exim_mainlog
# chmod 0640 /var/log/exim_mainlog
# service exim start

Linux exim komutları


Basic information

Print a count of the messages in the queue:

root@localhost# exim -bpc

Print a listing of the messages in the queue (time queued, size, message-id, sender, recipient):

root@localhost# exim -bp

Print a summary of messages in the queue (count, volume, oldest, newest, domain, and totals):

root@localhost# exim -bp | exiqsumm

Print what Exim is doing right now:

root@localhost# exiwhat

Test how exim will route a given address:

root@localhost# exim -bt alias@localdomain.com
<-- alias@localdomain.com
router = localuser, transport = local_delivery
root@localhost# exim -bt user@thishost.com
router = localuser, transport = local_delivery
root@localhost# exim -bt user@remotehost.com
router = lookuphost, transport = remote_smtp
host mail.remotehost.com [] MX=0

Run a pretend SMTP transaction from the command line, as if it were coming from the given IP address. This will display Exim’s checks, ACLs, and filters as they are applied. The message will NOT actually be delivered.

root@localhost# exim -bh

Display all of Exim’s configuration settings:

root@localhost# exim -bP

Searching the queue with exiqgrep

Exim includes a utility that is quite nice for grepping through the queue, called exiqgrep. Learn it. Know it. Live it. If you’re not using this, and if you’re not familiar with the various flags it uses, you’re probably doing things the hard way, like piping `exim -bp` into awk, grep, cut, or `wc -l`. Don’t make life harder than it already is.

First, various flags that control what messages are matched. These can be combined to come up with a very particular search.

Use -f to search the queue for messages from a specific sender:

root@localhost# exiqgrep -f [luser]@domain

Use -r to search the queue for messages for a specific recipient/domain:

root@localhost# exiqgrep -r [luser]@domain

Use -o to print messages older than the specified number of seconds. For example, messages older than 1 day:

root@localhost# exiqgrep -o 86400 [...]

Use -y to print messages that are younger than the specified number of seconds. For example, messages less than an hour old:

root@localhost# exiqgrep -y 3600 [...]

Use -s to match the size of a message with a regex. For example, 700-799 bytes:

root@localhost# exiqgrep -s ‘^7..$’ [...]

Use -z to match only frozen messages, or -x to match only unfrozen messages.

There are also a few flags that control the display of the output.

Use -i to print just the message-id as a result of one of the above two searches:

root@localhost# exiqgrep -i [ -r | -f ] …

Use -c to print a count of messages matching one of the above searches:

root@localhost# exiqgrep -c …

Print just the message-id of the entire queue:

root@localhost# exiqgrep -i

Managing the queue

The main exim binary (/usr/sbin/exim) is used with various flags to make things happen to messages in the queue. Most of these require one or more message-IDs to be specified in the command line, which is where `exiqgrep -i` as described above really comes in handy.

Start a queue run:

root@localhost# exim -q -v

Start a queue run for just local deliveries:

root@localhost# exim -ql -v

Remove a message from the queue:

root@localhost# exim -Mrm [ … ]

Freeze a message:

root@localhost# exim -Mf [ … ]

Thaw a message:

root@localhost# exim -Mt [ … ]

Deliver a message, whether it’s frozen or not, whether the retry time has been reached or not:

root@localhost# exim -M [ … ]

Deliver a message, but only if the retry time has been reached:

root@localhost# exim -Mc [ … ]

Force a message to fail and bounce as “cancelled by administrator”:

root@localhost# exim -Mg [ … ]

Remove all frozen messages:

root@localhost# exiqgrep -z -i | xargs exim -Mrm

Remove all messages older than five days (86400 * 5 = 432000 seconds):

root@localhost# exiqgrep -o 432000 -i | xargs exim -Mrm

Freeze all queued mail from a given sender:

root@localhost# exiqgrep -i -f luser@example.tld | xargs exim -Mf

View a message’s headers:

root@localhost# exim -Mvh

View a message’s body:

root@localhost# exim -Mvb

View a message’s logs:

root@localhost# exim -Mvl

Add a recipient to a message:

root@localhost# exim -Mar


… ]

Edit the sender of a message:

root@localhost# exim -Mes

Access control

Exim allows you to apply access control lists at various points of the SMTP transaction by specifying an ACL to use and defining its conditions in exim.conf. You could start with the HELO string.

# Specify the ACL to use after HELO
acl_smtp_helo = check_helo

# Conditions for the check_helo ACL:

deny message = Gave HELO/EHLO as “friend”
log_message = HELO/EHLO friend
condition = ${if eq {$sender_helo_name}{friend} {yes}{no}}

deny message = Gave HELO/EHLO as our IP address
log_message = HELO/EHLO our IP address
condition = ${if eq {$sender_helo_name}{$interface_address} {yes}{no}}


NOTE: Pursue HELO checking at your own peril. The HELO is fairly unimportant in the grand scheme of SMTP these days, so don’t put too much faith in whatever it contains. Some spam might seem to use a telltale HELO string, but you might be surprised at how many legitimate messages start off with a questionable HELO as well. Anyway, it’s just as easy for a spammer to send a proper HELO than it is to send HELO im.a.spammer, so consider yourself lucky if you’re able to stop much spam this way.

Next, you can perform a check on the sender address or remote host. This shows how to do that after the RCPT TO command; if you reject here, as opposed to rejecting after the MAIL FROM, you’ll have better data to log, such as who the message was intended for.

# Specify the ACL to use after RCPT TO
acl_smtp_rcpt = check_recipient

# Conditions for the check_recipient ACL

# [...]

drop hosts = /etc/exim_reject_hosts
drop senders = /etc/exim_reject_senders

# [ Probably a whole lot more... ]

This example uses two plain text files as blacklists. Add appropriate entries to these files – hostnames/IP addresses to /etc/exim_reject_hosts, addresses to /etc/exim_reject_senders, one entry per line.

It is also possible to perform content scanning using a regex against the body of a message, though obviously this can cause Exim to use more CPU than it otherwise would need to, especially on large messages.

# Specify the ACL to use after DATA
acl_smtp_data = check_message

# Conditions for the check_messages ACL

deny message = “Sorry, Charlie: $regex_match_string”
regex = ^Subject:: .*Lower your self-esteem by becoming a sysadmin


Fix SMTP-Auth for Pine

If pine can’t use SMTP authentication on an Exim host and just returns an “unable to authenticate” message without even asking for a password, add the following line to exim.conf:

begin authenticators

driver = plaintext
public_name = PLAIN
server_condition = “${perl{checkuserpass}{$1}{$2}{$3}}”
server_set_id = $2
> server_prompts = :

This was a problem on CPanel Exim builds awhile ago, but they seem to have added this line to their current stock configuration.
Log the subject line

This is one of the most useful configuration tweaks I’ve ever found for Exim. Add this to exim.conf, and you can log the subject lines of messages that pass through your server. This is great for troubleshooting, and for getting a very rough idea of what messages may be spam.

log_selector = +subject

Reducing or increasing what is logged.
Disable identd lookups

Frankly, I don’t think identd has been useful for a long time, if ever. Identd relies on the connecting host to confirm the identity (system UID) of the remote user who owns the process that is making the network connection. This may be of some use in the world of shell accounts and IRC users, but it really has no place on a high-volume SMTP server, where the UID is often simply “mail” or whatever the remote MTA runs as, which is useless to know. It’s overhead, and results in nothing but delays while the identd query is refused or times out. You can stop your Exim server from making these queries by setting the timeout to zero seconds in exim.conf:

rfc1413_query_timeout = 0s

Disable Attachment Blocking

To disable the executable-attachment blocking that many Cpanel servers do by default but don’t provide any controls for on a per-domain basis, add the following block to the beginning of the /etc/antivirus.exim file:

if $header_to: matches “example\.com|example2\.com”

It is probably possible to use a separate file to list these domains, but I haven’t had to do this enough times to warrant setting such a thing up.
Searching the logs with exigrep

The exigrep utility (not to be confused with exiqgrep) is used to search an exim log for a string or pattern. It will print all log entries with the same internal message-id as those that matched the pattern, which is very handy since any message will take up at least three lines in the log. exigrep will search the entire content of a log entry, not just particular fields.

One can search for messages sent from a particular IP address:

root@localhost# exigrep ‘<= .* \[\] ' /path/to/exim_log

Search for messages sent to a particular IP address:

root@localhost# exigrep ‘=> .* \[\]‘ /path/to/exim_log

This example searches for outgoing messages, which have the “=>” symbol, sent to “user@domain.tld”. The pipe to grep for the “<=" symbol will match only the lines with information on the sender - the From address, the sender's IP address, the message size, the message ID, and the subject line if you have enabled logging the subject. The purpose of doing such a search is that the desired information is not on the same log line as the string being searched for.

root@localhost# exigrep ‘=> .*user@domain.tld’ /path/to/exim_log | fgrep ‘<='

Generate and display Exim stats from a logfile:

root@localhost# eximstats /path/to/exim_mainlog

Same as above, with less verbose output:

root@localhost# eximstats -ne -nr -nt /path/to/exim_mainlog

Same as above, for one particular day:

root@localhost# fgrep YYYY-MM-DD /path/to/exim_mainlog | eximstats


To delete all queued messages containing a certain string in the body:

root@localhost# grep -lr ‘a certain string’ /var/spool/exim/input/ | \
sed -e ‘s/^.*\/\([a-zA-Z0-9-]*\)-[DH]$/\1/g’ | xargs exim -Mrm

Note that the above only delves into /var/spool/exim in order to grep for queue files with the given string, and that’s just because exiqgrep doesn’t have a feature to grep the actual bodies of messages. If you are deleting these files directly, YOU ARE DOING IT WRONG! Use the appropriate exim command to properly deal with the queue.

If you have to feed many, many message-ids (such as the output of an `exiqgrep -i` command that returns a lot of matches) to an exim command, you may exhaust the limit of your shell’s command line arguments. In that case, pipe the listing of message-ids into xargs to run only a limited number of them at once. For example, to remove thousands of messages sent from joe@example.com:

root@localhost# exiqgrep -i -f ‘‘ | xargs exim -Mrm

Speaking of “DOING IT WRONG” — Attention, CPanel forum readers

I get a number of hits to this page from a link in this post at the CPanel forums. The question is:

Due to spamming, spoofing from fields, etc., etc., etc., I am finding it necessary to spend more time to clear the exim queue from time to time. [...] what command would I use to delete the queue

The answer is: Just turn exim off, because your customers are better off knowing that email simply isn’t running on your server, than having their queued messages deleted without notice.

Or, figure out what is happening. The examples given in that post pay no regard to the legitimacy of any message, they simply delete everything, making the presumption that if a message is in the queue, it’s junk. That is total fallacy. There are a number of reasons legitimate mail can end up in the queue. Maybe your backups or CPanel’s “upcp” process are running, and your load average is high — exim goes into a queue-only mode at a certain threshold, where it stops trying to deliver messages as they come in and just queues them until the load goes back down. Or, maybe it’s an outgoing message, and the DNS lookup failed, or the connection to the domain’s MX failed, or maybe the remote MX is busy or greylisting you with a 4xx deferral. These are all temporary failures, not permanent ones, and the whole point of having temporary failures in SMTP and a mail queue in your MTA is to be able to try again after awhile.

Exim already purges messages from the queue after the period of time specified in exim.conf. If you have this value set appropriately, there is absolutely no point in removing everything from your queue every day with a cron job. You will lose legitimate mail, and the sender and recipient will never know if or why it happened. Do not do this!

If you regularly have a large number of messages in your queue, find out why they are there. If they are outbound messages, see who is sending them, where they’re addressed to, and why they aren’t getting there. If they are inbound messages, find out why they aren’t getting delivered to your user’s account. If you need to delete some, use exiqgrep to pick out just the ones that should be deleted.
Reload the configuration

After making changes to exim.conf, you need to give the main exim pid a SIGHUP to re-exec it and have the configuration re-read. Sure, you could stop and start the service, but that’s overkill and causes a few seconds of unnecessary downtime. Just do this:

root@localhost# kill -HUP `cat /var/spool/exim/exim-daemon.pid`

You should then see something resembling the following in exim_mainlog:

pid 1079: SIGHUP received: re-exec daemon
exim 4.52 daemon started: pid=1079, -q1h, listening for SMTP on port 25 (IPv4)

Read The Fucking Manual

The Exim Home Page

Documentation For Exim

The Exim Specification – Version 4.5x

Exim command line arguments

Go to Top