Category: VPS

How does the switch over to a VPS from shared hosting take place?

Question:

I want to switch from my shared hosting to a VPS. How can this be done so that I have no downtime? What is the normal process?

Answer:

Normally we do this:

1. Set your DNS TTL to a short value. Normally 3 minutes.

2. Clone your site (files and databases) to the VPS.

3. Send you the raw IP of the VPS to check things out on. Depending on the way your site is coded this may not work perfect (ie. your code keeps trying to redirect you to the proper domain name).

4. If all is well, you contact us and tell us to switch it over

5. We do one final sync of your db and files (in case anything changed from the time we first cloned your site). This step is optional. Let us know if you want a final sync done. If you’ve made tweaks to the VPS copy of the site you will NOT want this done as it will overwrite your changes.

6. The site goes live. If anything is wrong, you let us know and we switch it back

We keep your DNS TTL to about 3 minutes so if something is wrong, your users will pretty quickly (in theory no longer than 3 minutes) start hitting the “old” server again.

Delete mysql user example and tutorial

Note: deleting mysql users will not work on most types of shared accounts. You will likely need to enter a support request unless you have a VPS.

Here’s how to delete a user mysql from.

In the example the test user is called “jdoe”

This step is not necessary but you can use it to verify you are removing the intended username :


mysql> show grants for jdoe;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for jdoe@% |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'jdoe'@'%' IDENTIFIED BY PASSWORD '*4CB51346C69F4302F0371CB61DE7076D14837C48' |
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `jdoedb`.* TO 'jdoe'@'%' |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Next, perform the actual removal of the user:

mysql> drop user jdoe;
Query OK, 0 rows affected (0.08 sec)

Next run flush privileges – this is likely not needed. However lacking time to look up the correct answer I’m going to call it anyway. When in doubt, remember that flushing privileges never hurts anything. It simply reloads all the privileges currently assigned (thus “unloading” any that are deleted and should be removed).

mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)

If you want to verify the user was deleted, run the show grants command again:

mysql> show grants for jdoe;
ERROR 1141 (42000): There is no such grant defined for user 'jdoe' on host '%'

It should come back empty now.

Shared hosting versus VPS downtimes

Question:

How often should I expect downtime on a shared account versus a VPS?

Answer:

If you picked a random shared server, you could expect about one five minute outage every 5 months due to kernel upgrades. This is an average because there is no way to tell for certain when new (required – security related) kernels will be released. Think of a kernel update as a required security upgrade that needs a reboot to be installed.

On a shared server other outages are totally dependent on the machine itself and the hard to foresee mix of user websites loaded onto it. On a shared machine it is very hard to 100% stop a user with problems from affecting everyone else.

On a VPS you are in a much better position. You still have occasional reboots for kernel upgrades (we handle these automatically for you). All other parts of your server are totally private so you do not need to worry about other users causing downtime. As long as your own scripts do not cause out of memory and and other problems your VPS should run without issue.

Adding Silverlight support to Apache (mime.types)

Question:

Do I need to make any changes for the Apache webserver to support Silverlight apps?

Answer:

In most cases, no changes need to be made.

If you are having problems, try adding:

application/manifest manifest
application/xaml+xml xaml
application/x-ms-application application
application/x-ms-xbap xbap
application/octet-stream deploy
application/vnd.ms-xpsdocument xps
application/xaml+xml xaml
application/x-silverlight-app xap

to your mime.types file

Don’t forget to restart apache with:

/usr/local/apache/bin/apachectl graceful

after you make the change.

External VPS firewall options

Question:

Is there an external firewall for my VPS?

Answer:

By default there is no firewall for your connection. Your VPS provides excellent firewalling via the built-in iptables firewall/filter. You have full control over iptables to firewall traffic as you see fit.

We do reserve the right to firewall ports externally if any problems would occur – attacks, spam problem, etc.

As an example, if your server were to be compromised and attacked others we may firewall all ports except ssh until you are able to connect and fix the problem, etc.

VPS monitoring

Question:

Can you monitor my VPS?

Answer:

By default we perform monitoring of the physical node only. However we can also can provide informal monitoring of your httpd as well. To start monitoring, send us a message when your VPS is in production and we’ll monitor httpd. If it goes down, we’ll attach and investigate. If it is a simple issue, we will make any needed changes and restart. If you have made previous plans for extended support our engineers can perform “what-ever-it-takes” measures to put your httpd back online. Without a prior agreement, we’ll wait for you to connect and investigate the problem. Our staff does want to see you back online asap but without a previous plan and knowledge of your particular configuration it can often cause more harm than good for our staff to start adjusting your configuration.

As always, you can contact support and we can setup a support agreement that is best for your needs.

VPS maintenance – upgrades, security, etc.

Question:

How does maintenance work on a VPS?

Answer:

Regarding maintenance, we handle all kernel updates (openvz/virtuozzo uses a shared kernel approach so kernel modifications can only be done by us on the host node). To avoid surprises, all other updates are left to you as the administrator of your server to perform. Once you have your VPS you are free to change, modify, delete anything you like so it is not practical for us to make updates as we may mistakenly break things you modified if we did updates.

The one exception is that we reserve the right to force upgrades in a critical situation. For example, if there was a new “0 day” exploit for ssh we would (at our discretion) attach to your VPS and force an upgrade. This option is reserved for rare cases where, in our judgment, it is critical that an update be applied.

If you need full maintenance of your VPS, contact support and we can set up a separate support agreement for your VPS.

Upgrade php on centos (VPS)

Question: How do I upgrade php to the latest version on my VPS running centos?

Answer:

From the shell, run:

wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
wget ftp://ftp.muug.mb.ca/mirror/fedora/epel/5/i386/epel-release-5-4.noarch.rpm
rpm -Uvh epel-release-5-4.noarch.rpm remi-release-5.rpm
yum -y --enablerepo=remi update php mysql
/sbin/service httpd restart

You also may want to edit /etc/php.ini and change :

short_open_tag = Off

to

short_open_tag = On

without this change php code will only work when using the full:

 

<?php

 

open tag.