Dev {Tricks}

You are here: Home / Archives for dev

by

Migrate Accounts from CWP to CWP

To perform the migration you must follow a few simple steps:

  1. Generate an API Key on your Source CWP server.
    • CWP Settings >> API Manager
      (You can click on the CWP to CWP button and you will have the necessary options selected.)
  2. For the correct operation of this tool you must open port 2304 in the firewall of Source/Destination server.
    • Security >> CSF Firewall
  3. Open SSH port of the destination server if other than 22 in the firewall.
  4. Whitelist destination IP address.

 

Source server (Old Server)

To create a connection to your remote/source CWP server first you must generate an API Key on your Source CWP server, To create an API key/token, use API Manager (CWP Settings >> API Manager). You can click on the CWP to CWP button and you will have the necessary options selected.

Log in to the CWP panel.

  • First check your SSH port

    • Go to Services config > SSH Configuration
    • Or login to terminal and check
vi /etc/ssh/sshd_config
    • Port 2251
    • By default the port is 22, if you did not change it.
    • Then check and open TCP port. Note that you must have to add the port 2304 additionally for migration to done successfully.
  • Go to Dashboard, then click on Firewall
    • You will find “Opened TCP \ UDP ports” on the right sidebar
    • If it is not listed to TCP IN and TCP OUT
    • Go to Firewall Configuration > Main Configuration on top menu of this page
    • This will open Contents of File: /etc/csf/csf.conf
    • Go to #Allow incoming TCP ports and add your port. In my case Port 2251 and extra port for migration 2304
# Allow incoming TCP ports
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2030,2031,2082,2083,2086,2087,2095,2096,2304,2251"

# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,53,80,110,113,443,2030,2031,2082,2083,2086,2087,2095,2096,587,993,995,2080,2443,2304,2251"
    • Save Changes
    • Go back to dashboard and go to Firewall again to check the port in TCP IN and OUT.
    • If everything ok, restart Firewall from the top of the menu.

  • Go back and add your Destination IP to whitelist.

    • Firewall Whitelist configuration > Add an entry add the Destination IP (New IP) and restart the firewall.
    • Note that if you whitelist IP you need not open port in all cases except Amazon S3, Google Cloud, Microsoft Azure or etc.

  • Now lets setup API connection

    • Go to CWP settings and select the option API Manager.
    • On the right top, you will find the button ‘Allow new API access’.
    • Click on it and you will get a popup window with a bunch of options.
      • Short Name: API Name. bdhostit
      • Ip Origin: Destination server IP that you want to authorize this API.
      • Key code: Click on “Generate” and save it somewhere.
        GaKPCAv3qCGpfTd2fr5IQIaxmxCIZjQJKLGgOsGHHltJa4vmpft180kfIzKfbhpB34B9HA
      • Owner: root
      • Format Request: JSON
        Select the JSON format and enable the function for the cwp to cwp move.
      • You can select CWP to CWP option to enable all functions for CWP to CWP migration.
    • Enable Functions for
      • CWP to CWP
      • WHMCS
      • CLUSTER CWP
      • OR
        You can set permission to the API to do the transfer manually.
    • The necessary functions are
      • Account (add, list)
      • Packages (add, list)
      • MySQL Databases (add, list)
      • MySQL Users (add, list)
      • Change of the password (upd)
      • Cronjobs Users (add, upd ).
      • You can add others as well based on your needs.

  • Now you have to create SSK Key

    • Server Settings > SSH Key Generator and then click on Generate new key
    • Test SSH
ssh root@185.215.164.96 -p 6316
ssh root@38.242.204.74 -p 63160 "whoami"

Destination Server (New server)

Log in to the CWP panel

Click on Firewall and Go to Whitelist configuration > Add an entry add the Source IP (Old IP) and restart the firewall.

Now go to User Accounts > CWP to CWP Migration

 

by

How to Install WordPress through webmin?

How to install WordPress on Webmin – Virtualmin and Usermin

  • Login to your Webmin Account where you want to install WordPress
  • Go to Virtualmin tab
  • Click on “Install Scripts”
  • You will find “WordPress” in the Available Scripts tab. Select it.
  • Click on “Show Install Options”
  • Now select or enter installation directory or sub-directory under public_html.
    • At top level
    • WordPress (directory)
  • Click on “Install now”
  • Confirm and click “Install now”
    • Are you sure you want to install WordPress into the directory /home/username/public_html? 4 files totalling 2.81 MiB already exist, and will be deleted if the script is un-installed.
  • Click on the link
    • WordPress initial installation finished. It can be completed at https://domain.com/wp-admin/install.php.
  • Select Language
  • Provide information needed
    • Welcome to the famous five-minute WordPress installation process! Just fill in the information below and you’ll be on your way to using the most extendable and powerful personal publishing platform in the world.
  • Click on “Install WordPress”
  • That’s ALL!

 

by

How to install webmin, usermin, virtualmin

Install your Operating System

List of supported OS:

  • CentOS/RHEL Linux 7, and 8 on x86_64
  • Debian 9, and 10 on i386 and amd64
  • Ubuntu 16.04 LTS, 18.04 LTS, and 20.04 LTS on i386 and amd64

How to install Virtualmin/Webmin control panel in CentOS 7?  

Login to your server as root and follow the steps

  1. Let us update the packages before starting the installation process. 
    yum -y update
  2. Download the installer file with the below command for Virtualmin/Webmin control panel on CentOS 7. 
    wget http://software.virtualmin.com/gpl/scripts/install.sh
  3. Run the installer now with the below command. 
    chmod +x install.sh && ./install.sh
  4. You will be prompted. 
    Continue? (y/n)
  5. Write “y” and hit enter. The installation will start and it may take about 10-15 minutes to finish. 
    [INFO] Started installation log in /root/virtualmin-install.log
▣□□ Phase 1 of 3: Setup
Downloading RPM-GPG-KEY-virtualmin-6 [ ✔ ]
Downloading RPM-GPG-KEY-webmin [ ✔ ]
Installing Virtualmin 6 key [ ✔ ]
Installing Webmin key [ ✔ ]
Updating apt metadata [ ✔ ]
Downloading repository metadata [ ✔ ]
Enabling universe repositories, if not already available [ ✔ ]
Disabling cdrom: repositories [ ✔ ]
Cleaning out old metadata [ ✔ ]

▣▣□ Phase 2 of 3: Installation
Installing Webmin [ ✔ ]
Installing Usermin [ ✔ ]
Installing fail2ban [ ✔ ]
Removing nginx (if installed) before LAMP installation. [ ✔ ]
Removing unneeded packages that could conflict with LAMP stack. [ ✔ ]
Installing postfix [ ✔ ]
Installing virtualmin-lamp-stack [ ✔ ]
Installing Virtualmin and plugins [ ✔ ]
3 Feb 16:49:24 ntpdate[53399]: adjust time server 91.189.89.199 offset -0.000487 sec
Installing updates to Virtualmin-related packages [ ✔ ]

▣▣▣ Phase 3 of 3: Configuration
[1/23] Configuring AWStats [ ✔ ]
[2/23] Configuring Apache [ ✔ ]
[3/23] Configuring Bind [ ✔ ]
[4/23] Configuring ClamAV [ ✔ ]
[5/23] Configuring Dovecot [ ✔ ]
[6/23] Configuring Firewalld [ ✔ ]
[7/23] Configuring MySQL [ ✔ ]
[8/23] Configuring NTP [ ✔ ]
[9/23] Configuring Net [ ✔ ]
[10/23] Configuring ProFTPd [ ✔ ]
[11/23] Configuring Procmail [ ✔ ]
[12/23] Configuring Quotas [ ✔ ]
[13/23] Configuring SASL [ ✔ ]
[14/23] Configuring Shells [ ✔ ]
[15/23] Configuring SpamAssassin [ ✔ ]
[16/23] Configuring Status [ ✔ ]
[17/23] Configuring Upgrade [ ✔ ]
[18/23] Configuring Usermin [ ✔ ]
[19/23] Configuring Webalizer [ ✔ ]
[20/23] Configuring Webmin [ ✔ ]
[21/23] Configuring Fail2banFirewalld [ ✔ ]
[22/23] Configuring Postfix [ ✔ ]
[23/23] Configuring Virtualmin [ ✔ ]
▣▣▣ Cleaning up

[SUCCESS] Installation Complete!
  6. Now login to your webmin panel at https://serverip:10000 and create new virtual server. You may receive a security warning in your browser on your first visit.
    • You will be prompted for Post-Installation Wizard. Click on the next and select the appropriate setting for your system.
    • Install default virtual server and let’s Encrypt SSL
  7.  Multiple PHP Versions

by

intoDNS

 

Category Status Test name Information
Parent Info Domain NS records Nameserver records returned by the parent servers are:

//

e.gtld-servers.net was kind enough to give us that information.
Pass TLD Parent Check Good. e.gtld-servers.net, the parent server I interrogated, has information for your TLD. This is a good thing as there are some other domain extensions like “co.us” for example that are missing a direct check.
Pass Your nameservers are listed Good. The parent server e.gtld-servers.net has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers.
Pass DNS Parent sent Glue Good. The parent nameserver sent GLUE, meaning he sent your nameservers as well as the IPs of your nameservers. Glue records are A records that are associated with NS records to
provide “bootstrapping” information to the nameserver.(see RFC 1912 section 2.3)
Pass Nameservers A records Good. Every nameserver listed has A records. This is a must if you want to be found.
NS Info NS records from your nameservers NS records got from your nameservers listed at the parent NS are:

//
Pass Recursive Queries Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone.
Pass Same Glue The A records (the GLUE) got from the parent zone check are the same as the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do according to the RFC. This tests only nameservers that are common at the parent and at your nameservers. If there are any missing or stealth nameservers you should see them below!
Information Glue for NS records INFO: GLUE was not sent when I asked your nameservers for your NS records.This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records. The nameservers without glue are:

// 123.45.67.890
// 123.45.67.891

You can fix this for example by adding A records to your nameservers for the zones listed above.
Pass Mismatched NS records OK. The NS records at all your nameservers are identical.
Pass DNS servers responded Good. All nameservers listed at the parent server responded.
Pass Name of nameservers are valid OK. All of the NS records that your nameservers report seem valid.
Pass Multiple Nameservers Good. You have multiple nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me.
Pass Nameservers are lame OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
Pass Missing nameservers reported by parent OK. All NS records are the same at the parent and at your nameservers.
Pass Missing nameservers reported by your nameservers OK. All nameservers returned by the parent server e.gtld-servers.net are the same as the ones reported by your nameservers.
Pass Domain CNAMEs OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
Pass NSs CNAME check OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
Pass Different subnets OK. Looks like you have nameservers on different subnets!
Pass IPs of nameservers are public Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like
Pass DNS servers allow TCP connection OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default.
Pass Different autonomous systems OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down.
Pass Stealth NS records sent Ok. No stealth ns records are sent
SOA Info SOA record The SOA record is:
Primary nameserver: // grannbo.ns.cloudflare.com
Hostmaster E-mail address: // dns.cloudflare.com
Serial #: // 123456789
Refresh: // 10000
Retry: // 2400
Expire: // 604800   1 weeks
Default TTL: // 3600
Pass NSs have same SOA serial OK. All your nameservers agree that your SOA serial number is // 123456789.
Pass SOA MNAME entry OK. // grannbo.ns.cloudflare.com That server is listed at the parent servers.
Warn SOA Serial Your SOA serial number is: // 123456789. This can be ok if you know what you are doing.
Pass SOA REFRESH OK. Your SOA REFRESH interval is: // 10000. That is OK
Pass SOA RETRY Your SOA RETRY value is: // 2400. Looks ok
Pass SOA EXPIRE Your SOA EXPIRE number is: // 604800.Looks ok
Pass SOA MINIMUM TTL Your SOA MINIMUM TTL is: // 3600. This value was used to serve as a default TTL for records without a given TTL value and now is used for negative caching (indicates how long a resolver may
cache the negative answer). RFC2308 recommends a value of 1-3 hours. Your value of // 3600 is OK.
MX Info MX Records Your MX records that were reported by your nameservers are:

1   aspmx.l.google.com

123.45.67.890
(no glue)

5   alt1.aspmx.l.google.com

123.45.67.890
(no glue)

5   alt2.aspmx.l.google.com

123.45.67.890
(no glue)

10   alt3.aspmx.l.google.com

123.45.67.890
(no glue)

10   alt4.aspmx.l.google.com  123.45.67.890
(no glue)

[These are all the MX records that I found. If there are some non common MX records at your nameservers you should see them below. ]
Pass Different MX records at nameservers Good. Looks like all your nameservers have the same set of MX records. This tests to see if there are
any MX records not reported by all your nameservers and also MX records that have the same hostname but different IPs
Pass MX name validity Good. I did not detect any invalid hostnames for your MX records.
Pass MX IPs are public OK. All of your MX records appear to use public IPs.
Pass MX CNAME Check OK. No problems here.
Pass MX A request returns CNAME OK. No CNAMEs returned for A records lookups.
Pass MX is not IP OK. All of your MX records are host names.
Pass Number of MX records Good. Looks like you have multiple MX records at all your nameservers. This is a good thing and will help in preventing loss of mail.
Pass Mismatched MX A OK. I did not detect differing IPs for your MX records.
Pass Duplicate MX A records OK. I have not found duplicate IP(s) for your MX records. This is a good thing.
Pass Reverse MX A records (PTR) Your reverse (PTR) record:

98.7.654.321.in-addr.arpa ->  rc-in-f26.1e100.net

98.7.654.321.in-addr.arpa ->  wq-in-f26.1e100.net

98.7.654.321.in-addr.arpa ->  ta-in-f26.1e100.net

98.7.654.321.in-addr.arpa ->  sa-in-f26.1e100.net

98.7.654.321.in-addr.arpa ->  la-in-f27.1e100.net

You have reverse (PTR) records for all your IPs, that is a good thing.
WWW Info WWW A Record Your www.ajsrp.com A record is:
// www.domain.com

[104.26.5.40]

[172.67.72.134]

[104.26.4.40]
Pass IPs are public OK. All of your WWW IPs appear to be public IPs.
Pass WWW CNAME OK. No CNAME