HostsVault BlogHostsVault Blog

Its always annoying to move accounts around between servers because you have to coordinate lots of changes for example :

1- dns changes
2- minimizing downtime so you wont get users screaming at your face
3- notifying your users early enough (beware you will never be early enough)

In this tutorial we will guide you in step by step in how to perform a flawless migration.

Please note this tutorial is for migrating some accounts on the server not all the server, it will work well if you use the steps we mention on all accounts as well .

Now lets rock and roll.

First step has to be done 48-72 hours prior to migration (this used to be 24-48 hours back in the good old days when root nameservers acted correctly ) :

First we create a file named accounts which have the domains we need to transfer one domain in each line like this

domain1.com
domain2.com

Then run this command

for account in ` cat accounts `;do perl -pi.bak -e "s/14400/300/g if /^\s*\$TTL/" /var/named/$account.db;done
/etc/init.d/named restart

Here we have edited all  DNS zones listed in our accounts file and created a .bak of each (remember always backup). Changing the TTL (time To Live) from 14400 (4 hours) to 300 (5 minutes) means that as soon as we make a change to a DNS zone, it will take affect everywhere within 5 minutes as opposed to 4 hours, personally I find that this doesn’t work perfectly anymore but I will tell you how to overcome it ;) 

Now in the day designated for the migration

First we stop all services on the old server other than apache and MySQL ( to avoid loosing any emails or other stuff)

/etc/init.d/cpanel stop
/etc/init.d/exim stop
/etc/init.d/pure-ftpd stop;/scripts/ckillall -9 pure-ftpd;/scripts/ckillall -9 pure-authd
/etc/init.d/proftpd stop

After that login to WHM  on the new server as root then :

1- Click on copy multiple accounts
2- Fill out the old server data
3- Select accounts to transfer
4- Initiate the transfer process

Once the transfer has finished ssh to the old server and run this commands :

for account in ` cat accounts `;do perl -pi -e "s/[oldip]/[newip]/g" /var/named/$account.db;done
/etc/init.d/named restart

This will point all the sites to the newip. Hopefully most of your sites are on a shared ip. For all the accounts that are NOT on a shared ip we will need to edit that domain dns zone manually to reflect the new IP.

Transfer completed. Sites are functioning on new server, now transfer the nameservers! Here we go:

Be sure to set up your NEW nameservers on the NEW server. (WHM will only add an A record for the oldips) until you transfer the nameservers with the registrar) so you need to edit the DNS zones to reflect the new ips.

Submit the ip changes to your registrar and give it 48 hours to update. Within 48 hours your DNS will be served off your new server, thus you can cancel that old server with that host you couldn’t wait to leave.

If you have resellers, we have to copy all the files in /var/cpanel that reference resellers and anything ending in .accts to the new server.

Still one problem persists, some nameservers doesn’t respect TTL changes and work on their own schedule (usually 48 hours)

What can we do to overcome this , if we use iptables to route all traffic to the new ip we will face a problem cuz of the shared ip on the old server , we may have other domains still using it.

The solution to this problem is using Apache mod_proxy , here is how to do so:

Edit /usr/local/apache/conf/httpd.conf and inside each transferred site virtualhost directive and add this :

ProxyRequests Off
ProxyPass / http://domain.com/
ProxyPassReverse / http://domain.com/

If one of the domains has SSL certificate use this :

SSLProxyEngine On
ProxyRequests Off
ProxyPass / https://domain.com/
ProxyPassReverse / https://domain.com/

To assure that this domains resolves to the new ips you can edit /etc/hosts and add this domains with their new ips
Then mod_proxy will direct traffic to the new server.

Once the lagged nameservers have updated their cache – usually in 48 hours as I mentioned before – you will be good to go.

Migrating a server as a whole is a different story which strangely is easier but that’s a different article , hope this helps anyone out there .

One of our users demanded 2 mysql instances on his dedicated server as he had his  mysql hacked before on his previous host so he wanted to separate his own databases in a completely different directory and even using another MySQL process to assure physical separation I will show you here how to accomplish this

First create another mysql directory :

mkdir /var/lib/mysql2
chown mysql.mysql /var/lib/mysql2/

Then make a copy of your current my.cnf :

cp /etc/my.cnf /etc/my2.cnf

Next edit/add this inside your my2.cnf :

[mysqld]
pid-file = /var/lib//mysql2/mysql2.pid
socket = /var/lib/mysql2/mysql2.sock
port = 3300 # (or any other random port of your choice)
datadir = /var/lib/mysql2
log = /var/log/mysql2.log

Then you will have to initialize MySQL on your new datadir :

mysql_install_db --user=mysql --datadir=/var/lib/mysql2/

Now we are ready to start this instance

mysqld_safe --defaults-file=/etc/my2.cnf&

The reason of adding & in the end is to make this command run in the background and bring  you back to your normal bash shell.

But hey now how can I connect to this new instance ,its easy just use this command :

mysql -h localhost --port=3300

If you need to use mysqldump use this syntax :

mysqldump -s=/var/lib/mysql2/mysql2.sock dbase_name > db.sql

for an added layer of security you can disable remote MySQL access by adding this under [mysqld] section in your my2.cnf :

skip-networking

Sometimes You may notice your server IP got blocked for being source of spam just cuz one of your users have got an easy to hack mailing form that hackers was able to inject e-mail addresses into it which caused you this problem
There are many methods to fight such spam attempts am here listing some using Apache’s modsecurity just add those lines to your modsecurity config (this works with modsecurity 2.X) :

SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}\,\x20[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"
SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}\,[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"
SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}\,\x20[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"
SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}\,[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"

Ugly rules isn’t it :) , this rules scan the body of the request (it should not contain any BCC or CC’ed emails) for e-mail pattern and blocks it accordingly, there are other methods to send spam without using your installed MTA the most famous one is direct mailer or dark mailer what ever dm.cgi stands for, this also can be blocked using modsecurity here are some rules that should help you doing that :

SecRule REQUEST_URI "dm.cgi"
SecRule REQUEST_BODY|REQUEST_URI "\.cgi\?m\=state"
SecRule REQUEST_BODY|REQUEST_URI "cgi\?m\=snd"
SecRule REQUEST_BODY|REQUEST_URI "cgi\?m\=icfg"

Fighting spam and insuring your server security is multiple layer process so you cant relay just on one solution you have to integrate them more than one and always go through your logs to assure everything is in place and nothing looks fishy.
For instance in this spam fighting issue you can handle and block this spam also using iptables but that’s another post, hope this post is helping anyone out there.

Ever found your account suddenly have been hacked with direct FTP login with no trials and errors as if the hacker knew your password if you have Joomla installed then its time to upgrade your Joomla installation, your safe if your joomla installation is 1.5.6 or higher for exploit details check here or here .

the exploit is based on SQL injection that would just bypass the token entry page bringing you to the change admin password page and voila your done changing the administrator password.

Combine this with Joomla FTP layer and the hacker will be able to grab the whole account password if the user just used it there, here are several approaches to resolve this issue :

Using Mod_security Version 2.0 :

 SecRule ARGS:task "confirmreset" chain
 SecRule REQUEST_BODY "!token=([a-z0-9]{32})"

Using Mod_security Version 1.0 :

SecFilterSelective ARG_task "confirmreset" chain
SecFilterSelective POST_PAYLOAD "!token=([a-z0-9]{32})"

Or by patching Joomla itself , edit the file components/com_user/models/reset.php
After global $mainframe; on line 113 of reset.php, add:

if(strlen($token) != 32) {
$this->setError(JText::_('INVALID_TOKEN'));
return false;
}

Now you should be safe from this exploit.

I know it’s a strange situation that probably wont happen but maybe you got stuck needing to copy files between two accounts on two different servers and your server admin have locked down access to FTP, rsync and scp ,here is how to copy this files regardless of all this restrictions all you need is nc (Netcat) and you don’t even need to be root

on the destination server run :

nc -l 1212 | gunzip -c | tar xvfp -

Explanation :
This will make netcat listen on port 1212 (make sure to use port over 1024 since you’re not root) piping all incoming content to gunzip to uncompress it then piping it again to tar creating files/directories with verbose switch on so you see what’s being created

On source server run :

tar cfp - /home/myuser/mydir | gzip -c | nc -w 10 destination_ip 1212

Explanation :
This will make tar start archiving your files under the directory you specified piping it to gzip for compression then to netcat that will pass it to destination_ip on designated port on timeout of 10 seconds just for sake of slow networks.

Hope this helps someone out there in the cyber space.

Don’t you all hate this plain format of bash history  :

  743  ls -al
  744  cd www
  745  ls -al
  746  cd ~

You don’t know what time or date this commands were used , so here is a tip to keep better tracking for your history (note this needs bash version 3 or more check by running bash –version ) :

nano /etc/bashrc

add this line to the bottom of the file :

export HISTTIMEFORMAT="%F %T "

From now on your log will look like this :

  743 2009-04-29 12:02:39 ls -al
  744 2009-04-29 12:02:39 cd www
  745 2009-04-29 12:02:39 ls -al
  746 2009-04-29 12:02:39 cd ~

Many Java application users may face this problem that their java virtual machine JVM is eating alot of memory , infact Java is greedy when allocting memory it will try allocating all the memory it can so  and wil share it with  other instances but this is a problem specially when your on a VPS and have limited memory .

You can limit the amount of memory Java  application uses by using this command when compiling  your application :

/usr/local/jdk/bin/javac -J-Xmx”amount of ram”  application.java

so for example to allocate 128 MB RAM only you run

/usr/local/jdk/bin/javac -J-Xmx128 application.java

You can limit the amount of m This way your application wouldn’t allocate more than 128 MB RAM.

You may face this situation where you need to migrate to a newer hardware/software server then find that your previous PostgreSQL version database is not compatible to the new 8.X version probably you have 7.X version here are the steps to migrate to this new version:

First on old server :

su - postgres
pg_dumpall > /tmp/db.out
exit

Then move the /tmp/db.out to the new server  on /tmp/db.out

On new server :

su - postgres
psql -f /tmp/db.out template1
exit

Once back as root :

service postgresql restart

Remember to erase or move /tmp/db.out  to somewhere not public , hope this helps anyone.

Credit for those thoughts goes to : Steve Stady and Seth Vidal

 1. do it the same, over and over and over again

2. Backups are sacred! If you do not know if your backups are current,
   then test them by restoring the data and comparing.
  
3. Do not make many, tiny partitions, make a smaller number
   of larger partitions, instead.

4. Why change the system default when you don’t have to?

5. Think now so you don’t have to later (at 4am).

6. If you have to do it more than once, automate it. If you cannot
   automate it, document it.
  
7. Personality is for people, not for computers.

8. “Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it.” – Brian W. Kernighan
   
9. If you do not know what a machine will do when it is rebooted, then
   it is not production ready.
  
10. Unless you write an essay on why you need to do something “special”
    use the tools, procedures, techniques and resources the OS provided
    for you.
   
11. Remember the Mack Truck Scenario: If no one will be able to figure
    this out if you get hit by a Mack truck, then you’re doing something
    wrong.
   
12. Revision Control! Comment!

13. Log and rotate logs. Log remotely for best effect.

14. Simplicity is its own reward.

15. If you haven’t thought of at least one potential negative outcome
    of hitting enter at the end of the command you just typed; then you
    don’t understand the command well enough to use it on a production
    system.
   
16. Use a unique marker for names of packages that are locally developed.
    $domainname perhaps?
   
17. If you cannot enumerate every port that should be listening on a given
    machine; then it is not production ready.
   
18. If the host firewalling allows access to more ports than ABSOLUTELY
    necessary; then the host is not production ready.

19. If it seems like someone else would have encountered this problem
    before, they probably have. We do not live in a vacuum. Google for
    the answer
       
20. DOCUMENT!

MySQL has different caching methods. Most of those are dependent on the storage engine that is used. For example the key buffer caches the indexes for MyISAM tables while the caching of data is left to the OS. InnoDB has the buffer pool for both data and indexes and so on. The query cache however, is independent of the storage engine that is used. Unlike most caches it does not store records or pages of data but complete result sets and the queries that caused those results to be returned. This is a very disputable concept since the way that it works is that if any of the tables used in a result set is modified, the whole cached result set is thrown out of the cache.

If your data is kinda static (not many change)  the query cache can give you an enormous performance boost. It even bypasses the query optimizer so that if the query is complex even more cpu time is saved. Knowing this you can optimize your application by changing complex queries into smaller queries that only use that data that never changes.

Of course there are some tricks to using the query cache. The first one is the size of the query cache. The default is 16MB which isn’t enough for shared-hosting  production servers. However, keep in mind that any memory assigned to the query cache is removed from another cache so it’s very important to strike a good balance. Of course the balance varies from one application to another. The second parameter is the maximum allowed result set size. It really doesn’t do any good to allow 16MB result sets into the cache because it would take only one poorly written query to flush out the entire cache.

So is query cache a good or bad thing? Well, in short, if your cache gets flushed out all the time and only adds to the overhead it’s usually better to assign the memory to storage engine dependent cache. If your data are constantly updating and inserts/updates most of your tables it will invalidate the results in the query cache pretty quickly and assigning memory to it is a waste of resources.

You can use MySQL Tuner for some quick information about the efficiency of the query cache.

Here is a sample config for my.cnf for a busy server so it can handle many requests , this setup is suitable for 4 GB RAM server running MySQL 5 :

[mysqld]
skip-name-resolve
thread_concurrency=4
max_connections=500
max_user_connections=8
key_buffer=512M
myisam_sort_buffer_size=64M
join_buffer_size=1M
read_buffer_size=2M
sort_buffer_size=2M
table_cache=1024
thread_cache_size=64
interactive_timeout=20
wait_timeout=15
connect_timeout=8
max_allowed_packet=16M
max_connect_errors=10
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
flush
flush_time=3600
long_query_time = 10
safe-show-database
collation_server=utf8_unicode_ci
character_set_server=utf8

[mysqld_safe]
open_files_limit=8192

[mysqldump]
quick
max_allowed_packet=16M

[myisamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M

[mysqlhotcopy]
interactive-timeout