yum install net-tools

Advertisements

—– For non-Wordpress site ——

This is the thing that got me when I was making the full transition to HTTPS for my blog. After changing the site name, all my CSS and JavaScript assets were still coming in with the HTTP URL path rather than HTTPS. This caused my site to appear broken in pretty much every browser.

These site asset files can easily be corrected by fixing the rewrite rules in your .htaccess file found at the root of your WordPress application.

# BEGIN WordPress
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{SERVER_PORT} !^443$    <---- Add this line
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]   <---- Add this line
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Notice the highlighted lines in the above code. We’re saying that if the current port isn’t 443, then rewrite the URL to use HTTPS with a 301 redirect. The rest of the above code should already exist in your WordPress .htaccess file. Usually it will be found at the bottom of the file.

 

If you want to force a given website or path to use https, redirected from http, you can create an .htaccess file in the DocumentRoot for that domain or hostname, and add the following code:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

which will redirect any non-https connections to https using the same request and GET variables.

If your site is running through CloudFlare, your https requests to it may actually hit your server in plaintext (http), which is confusing.
For that case, you might need something like this for an http to https redirect:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

where the only usable header is X-Forwarded-Proto, because the %{HTTPS} variable is “off” for requests from the CloudFlare network.

---

If you’re running nginx, go to:

Admin Level -> Custom Httpd Config -> domain.com

and in token |CUSTOM4|, add:

|*if SSL_TEMPLATE=”0″|
return 301 https://$host$request_uri;
|*endif|

 

 

 

 

TP SolusVM backups can get stuck on a SolusVM slave. The way SolusVM backups run is it creates an image of the server whilst it’s still running then places that image into a dump file where it stays whilst it is uploaded to your backup server. If the upload is interrupted then the image will stay in the dump file and take up space. You should remove this file and follow the below to restart the SolusVM backups.

First, let’s remove the file that the server uses to run backups

rm -rf /usr/local/solusvm/tmp/ftpbackup.pid

Then you need to restart the FTP service again by issuing;

php /usr/local/solusvm/includes/autoftpbackup.php
or
/usr/bin/php /usr/local/solusvm/includes/autoftpbackup.php --debug=1

If you see errors you can run this command with debugging to find out what is causing them;

php /usr/local/solusvm/includes/autoftpbackup.php --mode=all --debug=1

If you need imap compiled into php, run these pre-install commands:
CentOS

yum -y install pam-devel

Debian

apt-get install libc-client-dev

Once pre-install is done for your OS, run the following:

cd /root
wget files.directadmin.com/services/all/imap_php.sh
chmod 755 imap_php.sh
./imap_php.sh

supports both CustomBuild 1.x and 2.x.
For CB2, it will automatically detect the configure.phpX path.

#### Install software
wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod +x speedtest-cli

#### Run speed test
./speedtest-cli –server 2953 –share

 

Credit: https://www.cyberciti.biz/faq/install-speedtest-cli-on-centos-redhat-fedoa-scientific-to-measure-internetspeed/

curl -T /vz/dump/vzdump-001.tgz ftp://yourhostname.com/backups/ –user root:yourrootpass

yum -y update
/usr/bin/openssl req -x509 -newkey rsa:2048 -keyout /usr/local/directadmin/conf/cakey.pem -out /usr/local/directadmin/conf/cacert.pem -days 9000 -nodes
chown diradmin:diradmin /usr/local/directadmin/conf/cakey.pem
chmod 400 /usr/local/directadmin/conf/cakey.pem

cd /usr/local/directadmin/conf/
perl -pi -e ‘s/SSL=0/SSL=1/’ directadmin.conf
service directadmin restart

echo “letsencrypt=1” >> directadmin.conf
echo “enable_ssl_sni=1” >> directadmin.conf
cd /usr/local/directadmin/custombuild
./build update
./build rewrite_confs
./build letsencrypt
vi /etc/httpd/conf/extra/httpd-alias.conf
###### And make sure you see this line
Alias /.well-known “/var/www/html/.well-known”
service httpd restart
service directadmin restart

 

Then login to DirectAdmin UI and select menu named “SSL Certificates” at the user level.

Note: If you want the server hostname using LetsEncrypt then do below:
cd /usr/local/directadmin/scripts
./letsencrypt.sh request your.hostname.com 4096
cd /usr/local/directadmin/conf
perl -pi -e ‘s/SSL=0/SSL=1/’ directadmin.conf
echo “carootcert=/usr/local/directadmin/conf/carootcert.pem” >> directadmin.conf
echo “force_hostname=your.hostname.com” >> directadmin.conf
echo “ssl_redirect_host=your.hostname.com” >> directadmin.conf
service directadmin restart

 

—– Troubleshoot —-

Cannot Execute Your Request

Details

Getting challenge for parniagroup.com from acme-server…
User let’s encrypt key has been found, but not registered. Registering…
Account registration error. Response: HTTP/1.1 100 Continue
Expires: Wed, 03 Aug 2016 08:08:26 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: application/problem+json
Content-Length: 265
Boulder-Request-Id: vdS0ublv2yTS3g8BkAW4mjM9f-HCiYV6DgYrfCkaLqI
Replay-Nonce: QUnGB2x_ZY1sJRrGG3MgS9fwtegzDawR8xj1uJ4E50o
Expires: Wed, 03 Aug 2016 08:08:27 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 03 Aug 2016 08:08:27 GMT
Connection: close

{
“type”: “urn:acme:error:malformed”,
“detail”: “Provided agreement URL [https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf] does not match current agreement URL [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]”,
“status”: 400
}.

———————————————-

Well, they have changed their license agreement and that broke the Let’s Encrypt client used in DA. Please use CustomBuild 2.0 (at least rev. 1572) to update letsencrypt.sh script:

cd /usr/local/directadmin/custombuild
./build update
./build letsencrypt

Alternatively, “./build update_versions” can be used as well. The newest version of CustomBuild 2.0 is only available on files1.directadmin.com and files2.directadmin.com fileservers at the moment, other mirrors might take up to 24 hours to update.

To download the file manually (without CustomBuild), just execute:

wget -O /usr/local/directadmin/scripts/letsencrypt.sh http://files1.directadmin.com/services/all/letsencrypt.sh

If you see error like below in “Auto FTP backup” feature

/usr/local/solusvm/tmp/ftpbackup.pid already exists. Is backup already runing?

 

Just delete the file /usr/local/solusvm/tmp/ftpbackup.pid and the SolusVM backup will run fine.

rm -rf /usr/local/solusvm/tmp/ftpbackup.pid

Run this command on solusvm master node.

/usr/bin/php /usr/local/solusvm/includes/autoftpbackup.php –debug=1

Moving the SolusVM Master

1. Preparing the New Master

Install a new master server as explained in the Install Guide.

wget https://files.soluslabs.com/install.sh
sh install.sh

For CentOS 7

[root@vps ~]# systemctl stop httpd.service
[root@vps ~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.
[root@vps ~]# systemctl restart svmstack-nginx.service

2. Backing up the Original Database

You can backup your original SolusVM master database by entering the admin area and selecting System Tools > Database and clicking Send to Email or by downloading it directly.

3. Replacing the Encryption Key

Parts of your database are encoded using a unique encryption key stored in /usr/local/solusvm/includes/solusvm.conf. You need to make a copy of the encryption key on the original master and replace it on the new master.

The format of the solusvm.conf is as follows:

example: <DATABASENAME>:<USER>:<PASSWORD>:<HOST>:<the key is the last entry>

Icon

If you miss this step, non of your passwords or slave connections will work.

4. Restoring the Database

Upload the database backup to the new master server.

You can get the new database details from /usr/local/solusvm/includes/solusvm.conf, they are seperated with  ” :”.

example: <DATABASENAME>:<USER>:<PASSWORD>:<HOST>:<the key is the last entry>

Run this code in SSH on the new master to restore the database:

/usr/bin/mysql --user=USER --password=PASSWORD DATABASENAME < database.sql

If you change the IP of the master, you might need to reissue the license in solusvm.

5. Slave Configuration

Each slave in your cluster needs to know the new masters ip address (only if the masters ip is changed).

On each slave add the ip of your master to /usr/local/solusvm/data/allow.dat OR delete /usr/local/solusvm/data/allow.dat so it can be re-written.

6. OS Templates

Don’t forget to FTP, RSYNC etc. your OS templates to the new master.d

7. Update password for each node

Login to master node and select menu “edit node password” which you can get it from node server at /usr/local/solusvm/data/solusvm.conf

 

Source: https://documentation.solusvm.com/display/DOCS/Moving+the+SolusVM+Master