Empowering you with the knowledge to master Linux web hosting, DevOps and Cloud

 Linux Web Hosting, DevOps, and Cloud Solutions

Tag: cPanel

Install the free SSL Certificate on the server’s hostname – cPanel WHM server


cPanel and WHM (WebHost Manager) is a popular web hosting control panels that allow server administrators to manage web hosting services efficiently. Among their many features, cPanel offers a handy tool called AutoSSL, which provides free SSL certificates for added security. In this guide, I will show you how to use AutoSSL to secure your server’s hostname.

Step 1: The checkallsslcerts Script

The checkallsslcerts Script is used by cPanel to issue SSL certificates for server hostname. It’s important to note that checkallsslcerts
runs as part of the nightly update checks performed on your system. These updates include cPanel’s own update script, upcp (cPanel update script).

Step 2: When to Manually Run AutoSSL

In most cases, checkallsslcerts will take care of securing your server’s hostname during the nightly updates. However, there may be instances when you want to update the SSL certificate manually. This is especially useful if you’ve recently changed your server’s hostname and want to ensure the SSL certificate is updated immediately.

Step 3: Understanding the checkallsslcerts Script

The `/usr/local/cpanel/bin/checkallsslcerts` script is responsible for checking and installing SSL certificates for your server’s hostname. Here’s what the script does:

– It creates a Domain Control Validation (DCV) file.
– It performs a DNS lookup for your hostname’s IP address.
– It checks the DCV file using HTTP validation (for cPanel & WHM servers).
– If needed, it sends a request to Sectigo to issue a new SSL certificate.
– It logs the Sectigo requests for validation.

You can learn more about the checkallsslcerts script and it’s usage in this article from cPanel:

Step 4: How to Manually Execute the Script

To manually run the script, use the following command:

/usr/local/cpanel/bin/checkallsslcerts [options]

You can use options like `–allow-retry` and `–verbose` as needed.

Step 5: Troubleshooting and Tips

If you encounter issues with the SSL certificate installation, the script will provide helpful output to troubleshoot the problem. Ensure that your server’s firewall allows access from Sectigo’s IP addresses mentioned in the guide.

Common Issue: Unable to obtain a free hostname certificate due to 404 when DCV check runs in /usr/local/cpanel/bin/checkallsslcerts

After running the /usr/local/cpanel/bin/checkallsslcerts script via SSH, you may see errors similar to the following:

FAILED: Cpanel::Exception/(XID bj6m2k) The system queried for a temporary file at “http://hostname.domain.tld/.well-known/pki-validation/B65E7F11E8FBB1F598817B68746BCDDC.txt”, but the web server responded with the following error: 404 (Not Found). A DNS (Domain Name System) or web server misconfiguration may exist.
[WARN] The system failed to acquire a signed certificate from the cPanel Store because of the following error: Neither HTTP nor DNS DCV preflight checks succeeded!

Description:
Encountering errors like “404 Not Found” during the DCV check when running /usr/local/cpanel/bin/checkallsslcerts via SSH? This issue typically arises when the shared IP address doesn’t match the main IP. To resolve it, ensure both IPs match and that the A record for the server’s hostname points to the main/shared IP. Here’s a workaround:

Workaround:

1. Confirm that the main IP and shared IP are identical.
2. Make sure the A record for the server’s hostname points to the main/shared IP.
3. To change the shared IP:
Log in to WHM as the ‘root’ user.

  • Navigate to “Home » Server Configuration » Basic WebHost Manager® Setup.”
  • Update “The IPv4 address (only one address) to use to set up shared IPv4 virtual hosts” to match the main IP.
  • Click “Save Changes” and then execute the following via SSH or Terminal in WHM:
    /scripts/rebuildhttpdconf
    /scripts/restartsrv_httpd --hard

    This will help resolve issues with obtaining a free hostname certificate in cPanel/WHM.

    Conclusion

    Securing your cPanel/WHM server’s hostname with a free SSL certificate from AutoSSL is essential for a secure web hosting environment. By following these steps, you can ensure that your server’s hostname is protected with a valid SSL certificate.

    Remember to regularly check your SSL certificates to ensure they remain up-to-date and secure.

  • How To Install PHP 7 On A cPanel/WHM Server With EasyApache 3

    How To Install PHP 7 On A cPanel/WHM Server With EasyApache 3

    Latest versions of cPanel come with EasyApache 4 which provides lots of new features like native support for multiple PHP versions, PHP 7 support, very fast, etc. So it is recommended to migrate to EasyApache 4. However, if you cannot migrate EasyApache 4 because of some reason (Example: Tomcat support), you will have to compile the PHP 7 manually from source.

    To migrate to EasyApache for, just run the below command. cPanel will try to build a matching PHP setup using EasyApache 4.

    /scripts/migrate_ea3_to_ea4 --run

    If anything goes wrong during the upgrade process you can always go back with /scripts/migrate_ea3_to_ea4 –revert –run

    Manually install PHP 7

    Following steps are tested with cPanel 11.64.0.36 and CentOS 6.9 64 bit. The PHP handler should be suphp to get this working.

    cd /usr/local/src/
    wget http://php.net/distributions/php-7.0.22.tar.gz #Go to php.net site to find the latest version
    tar xvf php-7.0.22.tar.gz
    

    Build it.

     #./configure  --enable-bcmath --enable-calendar --enable-exif --enable-ftp --enable-gd-native-ttf --enable-libxml --enable-mbstring --enable-pdo=shared --enable-sockets --enable-zip --prefix=/usr/local/php70  --with-curl=/opt/curlssl/ --with-freetype-dir=/usr --with-gd --with-gettext --with-imap=/opt/php_with_imap_client/ --with-imap-ssl=/usr --with-jpeg-dir=/usr --with-kerberos --with-libdir=lib64 --with-libxml-dir=/opt/xml2/ --with-mcrypt=/opt/libmcrypt/ --with-mysqli --with-openssl=/usr --with-openssl-dir=/usr --with-pcre-regex=/opt/pcre --with-pdo-mysql=shared --with-pdo-sqlite=shared --with-pic --with-png-dir=/usr --with-xpm-dir=/usr --with-zlib --with-zlib-dir=/usr
    

    You may add any additional parameters required. You can run ./configure --help to see all available options first.
    Important: Do not forget to set the "--prefix=/usr/local/php70". Otherwise, your existing PHP installation will be lost.

     make
     make install
    

    If everything is successful, the PHP binaries will be installed in "/usr/local/php70/bin/" directory.

    Copy the default php.ini:

     cp -pr /usr/local/src/php-7.0.22/php.ini-production /usr/local/php70/lib/php.ini
    

    Add pdo,opcache, other modules to php.ini file.

     echo "extension=pdo.so" >> /usr/local/php70/lib/php.ini
     echo "extension=pdo_mysql.so" >> /usr/local/php70/lib/php.ini
     echo "zend_extension=opcache.so" >> /usr/local/php70/lib/php.ini
    

    Verify the installation

    /usr/local/php70/bin/php -v
    PHP 7.0.22 (cli) (built: Aug 5 2017 01:56:23) ( NTS )
    Copyright (c) 1997-2017 The PHP Group
    Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.22, Copyright (c) 1999-2017, by Zend Technologies

    Now link our new PHP 7 installation with Apache web server

    Generate the PHP config:

    cat >  /usr/local/apache/conf/php70.conf << EOF
    AddType application/x-httpd-php7 .php7 .php
    
        suPHP_AddHandler application/x-httpd-php7
    
    EOF
    

    Add new handler to suphp

    Edit the /opt/suphp/etc/suphp.conf and add below code, at the end of the handlers list to enable PHP7 handler.

    ;Handler for php-scripts
    #... existing handlers are here ... put yours below them
    application/x-httpd-php7="php:/usr/local/php70/bin/php-cgi"

    Now add our custom php config file to EasyApache list so that the changes will not be lost future EasyApache builds.

    There are two options here. You can either go into WHM and edit the post_virtualhost_global.conf file from there or you just run: vi /usr/local/apache/conf/includes/post_virtualhost_global.conf. Add the line below in that file and you should be all done.

    Include /usr/local/apache/conf/php70.conf

    Now restart Apache

    service httpd restart

    Configure a website To Use This new PHP 7
    Add following code to .htaccess file(/home/username/public_html/.htaccess)

    AddType application/x-httpd-php7 .php7 .php

    Disable/suspend email service for one domain – cPanel

    Disable/suspend email service for one domain

    From version 56, cPanel provides API support to disable email service for domain or email accounts. Please note this limit cannot be override by the user from their cPanel. This can be very helpful if there is any spamming activity and you just want to disable the email service feature for the domain for the time being.

    You can run the below commands through SSH console

    To suspend email service for a the cPanel user “aacenyor”

    whmapi1 suspend_outgoing_email user=aacenyor
    

    For unsuspending the account, please run the below command:

    whmapi1 unsuspend_outgoing_email user=aacenyor
    

    If you are not comfortable with SSH, you can also call these through browser XML.

    Example:

    To suspend
    https://hostname.example.com:2087/cpsess##########/xml-api/suspend_outgoing_email?api.version=1&user=aacenyor

    where replace hostname.example.com with your hostname
    replace cpsess########## with WHM session id.

    To un suspend
    https://hostname.example.com:2087/cpsess##########/xml-api/unsuspend_outgoing_email?api.version=1&user=aacenyor

    For older versions cPanel, you may refer to this below forum from cPanel. There is a workaround

    https://forums.cpanel.net/threads/how-do-i-block-one-domain-from-sending-email-from-my-server.223731/#post920912

    Blocking spoofed outgoing mails from your cPanel server

    Spoofing is where the mail headers are manipulated to appear as if the mail comes from some other domain. When emails are set to be from an email address on your domain and bounce, they are sent to our servers, attempting to deliver themselves to that mailbox. Generally, you will never see these emails; however, if the email spoofer happens to configure the “From:” header to be a real email box, the bounce will come back to your mailbox and you will receive the email. There is a high chance that a very large number of spam message already sent from server. This can cause high load in the server and sometimes leads to the blacklist of your mail server IP address.

    There are two ways in which a spoofed mail can be created.

    1. Exploiting vulnerable form to mail scripts to send out spoofed mails through local mail agent.
    2. Using stolen mail account login details to send spoofed mails through SMTP authentication.
    Let’s look at a solution on how spoofing can be prevented in Exim mail servers commonly implemented in cPanel/WHM servers.

    I. Blocking all un-authenticated spoofed outbound emails
    1. Login to WHM >> EXIM CONFIGURATION MANAGER >> ADVANCED EDITOR

    2. Add the following entry in the top using Add additional configuration setting:

    domainlist remote_domains = lsearch;/etc/remotedomains

    3. Add the following code under acl_not_smtp :

    deny
    condition = ${if ! match_domain{${domain:${address:$h_From:}}}{
    +local_domains : +remote_domains}}
    message = Sorry, you don’t have\
    permission to send email from this server with a header that\
    states the email is from ${lc:${domain:${address:$h_from:}}}.
    accept

    Here, the ACL will check for the presence of domain name part of the from address in either of the files – /etc/localdomains or /etc/remotedomains. If there is a mismatch, server will reject the email.

     

    II. Blocking all authenticated spoofed outbound emails
    1. WHM >> EXIM CONFIGURATION MANAGER >> ADVANCED EXIM EDITOR

    2. Search for acl_smtp_data and add the following lines under it:

    deny
    authenticated = *
    condition = ${if or {{ !eqi{$authenticated_id} {$sender_address} }\
    { !eqi{$authenticated_id} {${address:$header_From:}} }\
    }\
    }
    message = Your FROM address ( $sender_address , $header_From )
    must match your authenticated email user ( $authenticated_id ).
    Treating this as a spoofed email.
    Here, for all authenticated users, the rule will check whether the authenticated userid matches with the from address. If it matches, it will allow the email. Else, it will display the message “Your FROM must match your authenticated email user. Treating this as spoofed email”

     

    PS: If the acl_smtp_data is mentioned as something else(like acl_smtp_data = check_message), locate check_message and add the above lines just under it.
    IMPORTANT points to keep in mind
    a. POP before SMTP won’t work with this setting. You will have to ask your customers to use the option – “My Server Requires Authentication” in the SMTP settings of their email client.
    b. Username in the format user+domain.com will not work. They have to use user@domain.com instead.

    Also your customer cannot change the from field to something other than original authentcated user. People use this method in Website Contact forms.

     

    Setting SPF records

    Another way to prevent spoofing is using SPF records. You must specify valid spf records for your domain, so that only the intended people or server can send mails on behalf of your domain name.

    Apache: Multiple SSL websites on a single IP address

    Apache: Multiple SSL websites on a single IP address

    Update: This is a new update from a cPanel Tech
    “There is nothing to enable. As long as you are using cPanel & WHM version 11.38 on CentOS, RHEL, or CloudLinux version 6 or newer, SNI works out of the box”.

    One of the frustrating limitations in supporting secure websites has been the inability to share IP addresses among SSL websites.
    When website administrators and IT personnel are restricted to use a single SSL Certificate per socket (combination of IP Address and socket) it can cost a lot of money. Well we can actually share IP addresses for multiple secure websites. Solving this limitation required an extension to the Transport Layer Security (TLS) protocol that includes the addition of what hostname a client is connecting to when a handshake is initiated with a web server. The name of the extension is Server Name Indication (SNI). SNI is supported in Apache v2.2.12 , and OpenSSL v0.9.8j or later.

    With SNI, you can have many virtual hosts sharing the same IP address and port, and each one can have its own unique certificate

    Prerequisites to use SNI

    Use OpenSSL 0.9.8f or later
    Build OpenSSL with the TLS Extensions option enabled (option enable-tlsext; OpenSSL 0.9.8k and later has this enabled by default).
    Apache must have been built with that OpenSSL (./configure –with-ssl=/path/to/your/openssl). In that case, mod_ssl will automatically detect the availability of the TLS extensions and support SNI.
    Apache must use that OpenSSL at run-time, which might require setting LD_LIBRARY_PATH or equivalent to point to that OpenSSL, maybe in bin/envvars. (You’ll get unresolved symbol errors at Apache startup if Apache was built with SNI but isn’t finding the right openssl libraries at run-time.)

    Setting up SNI with Apache

    The configuration is pretty simple and straight forward, though I recommend making a backup of your existing httpd.conf file before proceeding.

    # Ensure that Apache listens on port 443
    Listen 443
    
    # Listen for virtual host requests on all IP addresses
    NameVirtualHost *:443
    
    # Go ahead and accept connections for these vhosts
    # from non-SNI clients
    SSLStrictSNIVHostCheck off
    
    # Because this virtual host is defined first, it will
    # be used as the default if the hostname is not received
    # in the SSL handshake, e.g. if the browser doesn't support
    # SNI.
    DocumentRoot /www/example2
    ServerName www.linuxwebhostingsupport.in
    
    # Other directives here
    SSLEngine On
    SSLCertificateFile /path/to/linuxwebhostingsupport.in.crt
    SSLCertificateKeyFile /path/to/linuxwebhostingsupport.in.key
    SSLCertificateChainFile /path/to/CA.crt
    
    DocumentRoot /www/example2
    ServerName www.abdulwahabmp.co.in
    
    # Other directives here
    SSLEngine On
    SSLCertificateFile /path/to/abdulwahabmp.co.in.crt
    SSLCertificateKeyFile /path/to/abdulwahabmp.co.in.key
    SSLCertificateChainFile /path/to/CA.crt

     

    That it!!!. Just restart APache service. Now go and check your Websites using https. That should be working.

    Plesk support SNI from 10.2.x version onwards.

    SNI will work on following Operating systems out of box

    OpenSuSE Linux 11.3 or later.
    Ubuntu Linux 10.4 or later.
    Debian Linux 6.0 or later.
    RedHat Linux 6.0 or later.
    CentOS Linux 60.0 or later

    Supported Desktop Browsers
    Internet Explorer 7 and later
    Firefox 2 and later
    Opera 8 with TLS 1.1 enabled
    Google Chrome:
    Supported on Windows XP on Chrome 6 and later
    Supported on Vista and later by default
    OS X 10.5.7 in Chrome Version 5.0.342.0 and later
    Chromium 11.0.696.28 and later
    Safari 2.1 and later (requires OS X 10.5.6 and later or Windows Vista and later).
    Note: No versions of Internet Explorer on Windows XP support SNI

     

    Installing and managing firewall using ConfigServer Firewall (CSF)

    ConfigServer firewall is a popular Linux firewall security suite. It is easy to install, flexible to configure and secure with extra checks.
    CSF is generally considered a more advanced firewall as there are more configuration options compared to other firewalls, while still being simple enough to install and configure that even novice administrators can use it. Some of the MANY functions of CSF are given below:-

    • Daemon process that checks for login authentication failures for:
    1. Courier imap, Dovecot, uw-imap, Kerio
    2.  openSSH
    3.  cPanel, WHM, Webmail (cPanel servers only)
    4. Pure-ftpd, vsftpd, Proftpd
    5. Password protected web pages (htpasswd)
    6. Mod_security failures (v1 and v2)
    7. Suhosin failures
    8. Exim SMTP AUTH
    9. Custom login failures with separate log file and regular expression matching

     

    • SSH login notification
    • SU login notification
    • SYN Flood protection
    • Ping of death protection
    • Port Scan tracking and blocking
    • IPv6 Support with ip6tables
    • …lots more!

    Removing Your Current Firewall
    To prevent any conflicts in operation we will need to remove your current firewall. The most common software firewalls on our dedicated servers are APF and CSF, so we have provided instructions on how to remove APF below. If you are using a different software firewall be sure to follow that programs uninstall directions before continuing. After completing the uninstall continue with the CSF installation below.
    Using Yum to Remove APF
    If it was installed via yum, which is most likely, you will first need to identify the name of your APF package:
    rpm -qa |grep -i apf
    In this case:
    [root@host ~]# rpm -qa | grep apf
    apf-9.6_5-1
    In order to remove that package, and get your server ready for CSF installation, run the following command:
    [root@host ~]# rpm -e apf-9.6_5-1
    If you see this:
    [root@host ~ ]# rpm -e apf-9.6_5-1
    error: Failed dependencies:
    apf >= 9.6_5-1 is needed by (installed) bfd-1.2-1.noarch
    It means you have BFD installed, and it will need to be removed before you can proceed to removing APF:
    [root@host ~ ]# rpm -e bfd-1.2-1.noarch
    Then attempt to remove apf again:
    [root@host ~ ]# rpm -e apf-9.6_5-1
    Any further dependency errors can be handled in the same way as long as you are aware of what you are removing. If you have any questions or get stuck at any point feel free to contact me here.
    Removing Source Installed APF
    This can be a bit trickier, and if you are not sure what you’re doing you may want to contact me . If you are confident and wish to proceed you will find a list of commands below that you can use to remove APF if it is installed in the most common CentOS directories.
    Stopping APF and iptables clears all of the rules from your firewall and ensures that removing the APF installation won’t cause access problems:
    [root@host ~ ]# /etc/init.d/iptables stop

    [root@host ~ ]# /etc/init.d/apf stop
    Remove all of the APF related files:
    [root@host ~ ]# rm -Rfv /etc/apf
    [root@host ~ ]# rm -fv /etc/cron.daily/fw
    [root@host ~ ]# rm -fv /etc/init.d/apf
    Remove APF from the list of programs that start at boot:
    [root@host ~ ]# chkconfig apf off

     

    Installing CSF

    So, login to your server via ssh and let’s start CSF installation by retrieving the package files using wget command:

    # wget http://configserver.com/free/csf.tgz

    Unpack the archive:

    # tar xfvz csf.tgz
    Navigate to the uncomperssed csf directory:

    # cd csf

     

    Check CSF will work on your server
    CSF provides a test script. We can check whether CSF works with your Server or not prior to installing it.

    #perl csftest.pl 

    Testing ip_tables/iptable_filter…OK
    Testing ipt_LOG…OK
    Testing ipt_multiport/xt_multiport…OK
    Testing ipt_REJECT…OK
    Testing ipt_state/xt_state…OK
    Testing ipt_limit/xt_limit…OK
    Testing ipt_recent…OK
    Testing xt_connlimit…OK
    Testing ipt_owner/xt_owner…OK
    Testing iptable_nat/ipt_REDIRECT…OK
    Testing iptable_nat/ipt_DNAT…OK

    RESULT: csf should function on this server

    If you get this output, you can proceed to installation. Otherwise you need to enable each missing modules and then install csf.

    Run the installer:
    Now there founr installation scripts
    install.cpanel.sh For cPanel
    install.directadmin.sh
    install.generic.sh
    install.sh

    csf installation for cPanel and DirectAdmin is preconfigured to work on those servers with all the standard ports open.. So install as per your requirement.

    #sh install.sh

    csf auto-configures your SSH port on installation where it’s running on a non-standard port. CSF also auto-whitelists your connected IP address where possible on installation.
    Configuration

    By default CSF is in Test mode. So you need to disable the test mode once you configured the firewall correctly. Then only the lfd daemon starts.

    “/etc/csf/csf.conf” is the main CSF configuration file.
    TCP_IN/TCP_OUT/UDP_IN/UDP_OUT = : These are the ports you want to leave open for your server to operate. If you change the default SSH port make sure to add it here. Also add any other services you might have running such as Shoutcast or game servers. All the ports not mentioed here will be blocked.

    LF_DSHIELD = 0: Change this option to 86400. This is an automatic updated list of known attacking IPs. Enabling this will stop them from being able to connect to your server.

    Spam Protection Alerts
    If you want to add some spam protection, CSF can help. Look in the configuration for the following:

    LF_SCRIPT_ALERT = 0 change this to 1. This will send an email alert to the system administrator when the limit configured below is reached within an hour.

    LF_SCRIPT_LIMIT = 100 change this to 250. This will alert you when any scripts sends out 250 email messages in an hour.
    Providing all the configuration options for CSF here is beyond the scope of the article. Please refer to this README from csf for more details

    Note:

    If you have installed CSF on cPanel/WHM, it also installs WHM plugin to manage CSF. You can access it from

    WHM >> Home >> Plugins >> CnfigServer Firewall
    Now TEST all your services to make sure everything is working – SSH, FTP, http. After you do a few quick tests go back into the Firewall Configuration page.

    TESTING = 1 change this to 0 and click Change at the bottom. Then Restart csf+lfd using below commands

    #csf -r
    Or
    #/etc/init.d/csf restart

    That’s it, the firewall is successfully installed and running!!
    Common commands:-

    To block an IP Permenently
    #csf -d IP

    To allow or whitelist IP permenently.
    #csf -a IP

    To temporary block IP
    #csf -td IP

    To temporary allow an IP
    #csf -ta IP

    To check an IP is blocked in firewall
    #iptables -nL | grep IP
    or
    # csf -g IP

    To find Reason for block.

    #grep IP /var/log/lfd.log

    To remove a permanent block
    #csf -dr IP

    To remove IP from allow list
    #csf -ar IP

    To disable csf
    #csf -x

    To enable CSF
    #csf -e

    To restart
    #csf -r
    CSF is an increasingly popular alternative to the stock firewalls on some servers. Should you require any other help , please contact me.

     

    Plesk to cPanel Manual migration

     

    Migrating accounts manually is a surprisingly simple task. All that needs to be done are the following:

    1. Populate /etc/trueuserdomains on the source server
    2. Package an account of your choice into a single file
    3. Copy the packaged account to the cPanel server
    4. Restore the account on the cPanel server

     

    Steps:-

    1. On the source server (Plesk), download the script that builds the list of accounts at /etc/trueuserdomains:

    # wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/updateuserdomains-universal
    
    and the script that packages the accounts:
    #wget http://httpupdate.cpanel.net/cpanelsync/transfers_DEVEL/pkgacct/packages-pXa
    
    
    2. Make them both of the scripts executable:
    # chmod +x updateuserdomains-universal
    # chmod +x pkgacct-*
    
    
    3. Execute updateuserdomains-universal:
    # ./updateuserdomains-universal
    Now there should be a plain text file at /etc/trueuserdomains that contains a list of accounts that can be packaged.
    
    4. To package an account, select a user from /etc/trueuserdomains (we'll use "alice" in the example below), and run the pkgacct script that we downloaded in the first step.
    # ./pkgacct-pXa alice
    
    his will package the entire account to a single file here:
    /home/cpmove-alice.tar.gz
    
    The amount of time that this process takes will depend on the size of the account. I would strongly advise running the "screen" command before packaging (and restoring) accounts. This will allow the package/restore processes to continue even if you get disconnected from the server.
    
    Also, if the /home directory is too small, you can specify which partition to use like this:
    # ./pkgacct-pXa alice /disk1
    where "/disk1" is only an example, and likely does not exist on your server. If it did, and if you ran that command, then you would end up with a file here:
    
    /disk1/cpmove-alice.tar.gz
    5. Copy the archive to the new server by running this from the source server:
    # scp /home/cpmove-alice.tar.gz root@x.x.x.x:/home
    
    
    6. On the cPanel server, after running "screen" (if you choose to use screen), run these commands to restore the account:
    # cd /home
    # /scripts/restorepkg cpmove-alice.tar.gz
    Leave a comment if you have any doubts
    Thanks!
    
    

    Server migration

    On occasion, you may want to move from one server to another. For example, you may be upgrading to a dedicated server or moving to a server with a different PHP deployment method. Server migration is a process in which data is moved from one server to another. Whatever the case, most people will agree that it is never a joyous event to switch server. Your sites will be down/unstable/inaccessible during the migration period and it could potentially lead to loss of sales. In this article, we are going to show you how you can migrate your site to a new server effortlessly and without any (or minimal) downtime. Below are the basic steps needs to be followed for a server migration with minimum downtime.

    1. Prepare Your DNS

    When you move your site(s) to a new server, you will likely get new IP addresses. The problem is that DNS servers cache domain name queries for as long as possible to provide the fastest response. Because of these DNS caching, once you change your IP, it can take up to three days before the changes propagate throughout the Internet. To keep this from happening, your first step in preparing for the migration is to change your DNS record TTL (Time To Live). This value designates how long your DNS entries should be cached. So the first thing you need to do before migrating is to lower the TTL to reasonable levels.

    2. Set up Your New Server

    Make sure your new server has the correct operating system installed and ready and that all hardware meets your applications specifications. Also setup the new IP addresses.

    3. Tune Your Server

    Check your file system and make sure your partitions are set up as you need them. Set up RAID if required. This is also the perfect time to implement any security practices within the OS and firewall (if installed). It’s important to complete these steps before you get too far because they’re much easier to do without content on the server.

    4. Install Base Applications

    Once you have installed the OS and setup the file system, you are ready to install the base applications, like the Web server, e-mail server, database server, PHP, etc.. Also verify the services are running fine on thr new server.

    5. Begin Data Migration

    Once the base applications are installed, you are ready to do the initial migration of your application data. This includes the database data, your application code files, mail server account configuration, logs, file caches, etc..

    6. Bring your new server to life.

    Once the data is migrated the server is configured to work everything correctly, you should change your sites domain DNS records to point to the new server address.

     

    Data Migration

    If you are using any Control Panels like cPanel, Plesk, etc., it rather easy to move data/accounts between servers as each control panel will give you option to move accounts.

    cPanel Server to cPanel server migration

    To migrate from one cPanel server to another, please do this:

    1. Log into WHM as root on the new cPanel server

    2. Click “Copy multiple accounts/packages from another server”

    3. Fill in the required information like source server details and click “Fetch Account List”

    You will then be given the option to choose which accounts and packages to transfer.

    cPanel also does support migraring accounts from different control panel other than cPanel itself.

     

    Server without a control panel

    Rsync is a simple and very powerfull tools which can be used to transfer files between servers efficently.

    First copy all the configurations files for the services like Webserver, Email server, etc. Then transfer the account data from old server.

    Rsync example:-

    #rsync -avz -e ssh /home root@remoteserverip:/home

    -v: verbose, will tell you what file its on, how many left to check, etc.
    -a: archive, will set most of the preferable options.
    –progress: gives you per-file data transfer rates, and spinning progress bars if you’re into that sort of thing.
    -z, –compress compress file data during the transfer

    System files:-

    Please note that we do not need to copy the server related files. We can exclude from the rync list. The most important excludes are the ones that reference hardware and system files that keep track of the server’s status while it’s running. That’s why directories like /boot, /proc, and /dev are essential excludes. The destination server should already have those directories and config files in place and they shouldn’t be overwritten.

    Example
    #rsync -avz -e ssh –exclude-from=”/home/exclude.txt” /home root@remoteserverip:/home

    Finalizing the migration

    Doing one pass got the more static files over to the new server. That’s good, but that may not be everything you needed to copy. An active database or a directory where a lot of files get created and deleted may have been copied but changed already. Or, more practically, they may have been in your exclude file.

    To get those last files you’ll want to bring the services that use them down. That way you know the entire file will be migrated with no changes made after your last sync.

    Edit your exclude file to remove references to the busy files you were holding off on then run the rsync command again.

    Powered by WordPress & Theme by Anders Norén