There is a bug in SolusVM that the network settings for CentOS 7 and Fedora 20 do not get provisioned properly when you initially order your VPS. This is due to the change in the way these operating systems use their network config files. Even though there is nothing we can do to fix this automated error, fortunately, you can fix the problem yourself with ease!

First, login to your virtual machine as root using VNC through your SolusVM control panel (since networking is not working, this is the only way).

Next, change your working directory to /etc/sysconfig/network-scripts/, you may do this by running the following command:

cd /etc/sysconfig/network-scripts

Next, you will need to rename your ifcfg-eth0 file to the new format used by CentOS 7 or Fedora 20 to the new one, ifcfg-ens3. That command for this change is as follows:

mv ifcfg-eth0 ifcfg-ens3

Next, you will need to edit the file and replace any occurrence of eth0 with ens3. You may do this with the following command:

sed -i — ‘s/ifcfg-eth0/ifcfg-ens3/g’ ifcfg-ens3

Alternatively: You can edit the file using vim and replace the ifcfg-eth0 occurrence by hand.

We also need to add the DNS servers. Do to this, edit the file /etc/sysconfig/network-scripts/ifcfg-ens3 and enter the following:

DNS1=8.8.8.8
DNS2=8.8.4.4

You also need to edit your resolv.conf file located at /etc/resolv.conf and add the following:

nameserver 8.8.8.8
nameserver 8.8.4.4

These addresses are the Google DNS resolvers so they are extremely fast no matter where you are in the world due to anycasting.

Next, restart networking with:

service network restart

You should now have Internet access! If you have any questions or problems regarding this fix, please feel free to contact the support department as the difficulty of this change may be difficult for beginners. We hope SolusVM has a fix for this soon!

 

Credit: https://www.meanservers.com/billing/knowledgebase/19/Network-Unavailable-with-CentOS-7-or-Fedora-20.html

Advertisements

yum install net-tools

—– 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