Pages

Tuesday, January 14, 2014

Migrated from Plesk, Ensim, or DirectAdmin To WHM

Sometimes, moving website accounts from servers like Plesk, Ensim, or DirectAdmin to cPanel using the usual automated tools can hit a snag. This might be due to slow network connections or small software glitches. The good news is that manually migrating an account is straightforward.


WHY MANUAL MIGRATION?

Automated migration tools are great, but they can fail if:

  • The connection between your old server and the new cPanel server is unreliable, causing the migration to time out.

  • There are known issues with the migration scripts that haven't been fixed yet.

In these cases, a simple manual process can save the day.


THE MANUAL MIGRATION PROCESS

Manually moving an account involves four main steps:

  1. Getting a list of accounts on your old server.

  2. Packaging a chosen account into a single file.

  3. Copying that packaged file to your new cPanel server.

  4. Restoring the account on the cPanel server.


STEP-BY-STEP GUIDE

Here’s how to do it:

1. PREPARE THE SOURCE SERVER

On your old server (Plesk, Ensim, or DirectAdmin), you need two scripts: one to list accounts and one to package them.

  • Download the account list script: wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/updateuserdomains-universal

  • Download the packaging script (choose one based on your old server type):

    • For Plesk: wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/pkgacct-pXa

    • For Ensim: wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/pkgacct-enXim

    • For DirectAdmin: wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/pkgacct-da

2. MAKE SCRIPTS EXECUTABLE

After downloading, you need to give these scripts permission to run:

  • chmod +x updateuserdomains-universal

  • chmod +x pkgacct-* (This command makes the specific pkgacct script you downloaded executable).

3. GENERATE THE ACCOUNT LIST

Run the updateuserdomains-universal script to create a list of accounts:

  • ./updateuserdomains-universal

This will create a file at /etc/trueuserdomains containing all the accounts that can be packaged.

4. PACKAGE THE ACCOUNT

Now, pick an account you want to move from the /etc/trueuserdomains file. For example, let's say the username is "alice". Run the appropriate packaging script (using pkgacct-pXa for Plesk in this example):

  • ./pkgacct-pXa alice

This command will create a single archive file, typically named /home/cpmove-alice.tar.gz. The time this takes depends on the account's size.

  • Important Tip: If your /home directory is full, you can specify another location for the packaged file. For example, to save it to /disk1: ./pkgacct-pXa alice /disk1 This would create /disk1/cpmove-alice.tar.gz.

  • Stay Connected (Optional but Recommended): Use the screen command before packaging and restoring. This ensures the process continues even if your connection to the server drops. Just type screen before running the packaging command.

5. COPY THE ACCOUNT TO THE NEW SERVER

You can copy the packaged account file (cpmove-alice.tar.gz) to your new cPanel server in two ways:

  • From the source server: scp /home/cpmove-alice.tar.gz root@x.x.x.x:/home (Replace x.x.x.x with your cPanel server's IP address)

  • From the cPanel server: cd /home scp root@x.x.x.x:/home/cpmove-alice.tar.gz . (Again, replace x.x.x.x with the source server's IP address)

6. RESTORE THE ACCOUNT ON THE CPANEL SERVER

Once the file is on your new cPanel server, navigate to the /home directory and restore the account. Remember to use screen here too if you chose to earlier.

  • cd /home

  • /scripts/restorepkg cpmove-alice.tar.gz

After a successful restore, you can delete the cpmove-alice.tar.gz file from /home to free up space.

Monday, December 16, 2013

Exim cheat sheet

Exim is a powerful mail transfer agent (MTA) used on many Linux servers. When emails can't be delivered immediately, they get put into a "queue." Managing this queue is crucial for server health and ensuring mail delivery. This guide provides quick commands for common Exim queue tasks.


CLEARING THE EXIM MAIL QUEUE

Sometimes, you need to clear out stuck or unwanted emails from the queue.

  • Remove All Mails: This command directly deletes all files from the input directory of the Exim spool, effectively clearing the entire queue. rm -rf /var/spool/exim/input/*

  • Delete All Frozen Mails: Frozen emails are those that Exim has temporarily stopped trying to deliver due to issues. exim -bpr | grep frozen | awk {'print $3'} | xargs exim -Mrm Alternatively, a more concise command: exiqgrep -z -i | xargs exim -Mrm

  • Delete Frozen Mails Older Than a Day: This is useful for clearing old, stalled messages without affecting newer ones. The 86400 represents seconds (1 day). exiqgrep -zi -o 86400 | xargs exim -Mrm You can change 86400 to any number of seconds for a different time frame.

  • Clear Spam Mails: If your logs indicate messages are marked as [SPAM]. grep -R -l [SPAM] /var/spool/exim/msglog/*|cut -b26-|xargs exim -Mrm

  • Clear Frozen Mails (Based on Log Entry): grep -R -l '*** Frozen' /var/spool/exim/msglog/*|cut -b26-|xargs exim -Mrm

  • Clear Mails for Unverified Recipients: grep -R -l 'The recipient cannot be verified' /var/spool/exim/msglog/*|cut -b26-|xargs exim -Mrm

  • Remove Mails from a Specific Sender (e.g., 'root'): Replace "" with the sender's email address or username, for example, root@yourhostname. exim -bp |grep ""|awk '{print $3}'|xargs exim -Mrm

  • Remove 'nobody' Mails: These often come from scripts. Replace HOSTNAME with your server's hostname.

    • From a specific sender (nobody@HOSTNAME): exiqgrep -i -f nobody@HOSTNAME | xargs exim -Mrm

    • For a specific recipient/domain (nobody@HOSTNAME): exiqgrep -i -r nobody@HOSTNAME | xargs exim -Mrm

  • Delete Mails for a Specific Domain: Replace yourdomain.com with the actual domain. exim -bp | grep "yourdomain.com" | awk {'print $3'} | xargs exim -Mrm


DELIVERING MAILS FROM THE QUEUE

If emails are stuck but should be delivered, you can force a delivery attempt.

  • Force Deliver All Mails: This command attempts to deliver all messages in the queue. The -P 40 option attempts 40 deliveries in parallel. exim -bpru |awk '{print $3}' | xargs -n 1 -P 40 exim -v -M

  • Flush the Mail Queue (Force Another Run): This tells Exim to process the queue again. exim -qff Alternatively: /usr/sbin/exim -qff exim -qf

  • Force Deliver Mails of a Particular Domain: Replace domain.com with the target domain. exim -v -Rff domain.com

  • Force Deliver a Specific Message: Replace MSGID with the message's unique ID. exim -M MSGID To view the transaction during delivery: exim -v -M MSGID


CHECKING THE EXIM MAIL QUEUE STATUS

These commands help you monitor the queue and inspect individual messages.

  • Exim Queue Summary: Provides details like count, volume, oldest, newest message, and domain breakdown. exim -bp | exiqsumm

  • Number of Frozen Mails: exim -bpr | grep frozen | wc -l

  • Total Number of Mails in Queue: exim -bpr | grep "<" | wc -l A simpler alternative: exim -bpc

  • View Mail in Queue for a User/Sender: Replace $name with the username or email address. exim -bp|grep $name

  • Check All Mails in the Queue: This lists all messages and their IDs. exim -bp

  • View Log for a Message: Replace message ID with the actual ID. exim -Mvl message ID

  • View Message Header: Replace $MSGID with the message ID. exim -Mvh $MSGID

  • View Message Body: Replace $MSGID with the message ID. exim -Mvb $MSGID


ADVANCED EXIM TOOLS

  • Simulate SMTP Transaction: This command helps debug Exim's checks, ACLs (Access Control Lists), and filters without actually sending a mail. Replace 127.0.0.1 with the IP you want to simulate from. exim -bh 127.0.0.1

  • Most Used Mailing Script Locations: This can help identify scripts sending a lot of mail. grep cwd /var/log/exim_mainlog | grep -v /var/spool | awk -F"cwd=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n

  • Check Syntactic Errors in Configuration: Use this when modifying Exim's configuration file. exim -C /config/file.new -bV

Wednesday, December 11, 2013

Understanding Mod_Security Database Connection Issues

You've encountered an error stating that the Mod_Security plugin can't connect to its database. Specifically, it's an "Access denied" error for the user 'modsec'@'localhost', even though a password was provided. This usually means the password Mod_Security is using to connect to the database is incorrect or the database user doesn't have the right permissions.


WHY THIS MATTERS

Mod_Security is a web application firewall that helps protect your website from various attacks. If it can't connect to its database, it might not be able to log security events or function correctly, leaving your website vulnerable.


HOW TO FIX IT

There are two main steps to resolve this, focusing on ensuring the 'modsec' user can properly access the 'modsec' database.

  1. Find the Correct Password Mod_Security is Using:

    The error indicates Mod_Security is trying to connect with a specific password. You need to find out what password it's actually configured to use.

    • Action: Run the following command in your server's terminal:

      grep dbpassword /etc/cron.hourly/modsecparse.pl
      
    • Explanation: This command searches a common Mod_Security configuration file (modsecparse.pl) for the line containing dbpassword. This line will reveal the password that Mod_Security is currently trying to use for its database connection. Let's say the output of this command shows the password is 'odu6lGYKAIyP'.

  2. Grant the Correct Permissions to the Database User:

    Once you know the password Mod_Security is configured with, you need to ensure the 'modsec' database user has the correct password and permissions in MySQL.

    • Action: Log into your MySQL server (as a root user or a user with sufficient privileges) and execute the following command. Replace 'odu6lGYKAIyP' with the actual password you found in the previous step.

      SQL
      GRANT ALL ON modsec.* TO 'modsec'@localhost IDENTIFIED BY 'odu6lGYKAIyP';
      FLUSH PRIVILEGES;
      
    • Explanation:

      • GRANT ALL ON modsec.*: This gives the 'modsec' user all permissions on all tables within the modsec database.

      • TO 'modsec'@localhost: Specifies that these permissions apply to the user 'modsec' when connecting from the 'localhost' (meaning from the same server).

      • IDENTIFIED BY 'odu6lGYKAIyP': Sets or updates the password for the 'modsec' user to 'odu6lGYKAIyP'. It's crucial that this password matches what Mod_Security is configured to use.

      • FLUSH PRIVILEGES;: This command reloads the grant tables in MySQL, applying the new permissions immediately.