posted on 2015-06-19 19:53:32
Migrating a website can be a tedious task, if you have problems keeping several things at once inside your head. This aims to solve this problem by presenting some proper guidelines.
Here we have a standard dynamic website with a mysql backend, served through an apache httpd.
For other databases/webservers the steps may differ in particular, but essentially this is the same theory everytime.
Mailmigration will as of now not be a part of this here, since it's gonna be long enough anyway.
Read this completely prior, as alternative ways are suggested sometimes.
This part is almost the most important, actual copying is usually not that hard if you know what you are doing. It's often harder to remember everything.
Before we start, the server can serve data of three kinds which are handled all the same way.
web data, just copy the website code database, copy the database dump file emails, copy the mailfiles
The server is accessed via the globally available...:
Basically these are the things you have to copy/adjust so things will go smooth.
Putting most of these questions plus the answers to them into a spreadsheed is not the worst idea. Maybe I will come up with a shell one-liner to create a .csv later.
Also it is helpful if you are able to do FXP (transfer files from one host directly to the other, without temporary saving the data/files locally), if you do not have SSH access.
server access via ssh is possible?
ssh works via key? or password only?
root account? (a lot of this guide assumes root privileges, I might have missed points there are no alternatives)
if not, do you have all necessary account credentials for all folders etc.?
DO THESE WORK?
if no ssh, do you have ftp credentials?
do the credentials actually work?
do you get a database dump you can transfer? (If you cannot access the server, you can't make a dump.)
are the folder accurately named?
how BIG is the webfolder? (so how long will copying take?)
which database management system is used? (i.e. mysql or postgres)
database credentials for it are?
what is the database the site is using actually called?
just how BIG is the database? (and so how long will copying take?)
what domains are pointing to the server?
are these actually active?
and can you change the DNS RR?
what are the DNS TTL times?
is mailing configured?
don't forget the DNS MX RR/RR's while at the last point
For finding out about the dns, if you have several virtual hosts on the same machine, try grepping them all there.
When having an apache,
grep all vhost files for
Here's a kind-of snippet, which will work if your apache vhost configs are in default locations and indented:
\grep -e '^\s\+Server' /etc/apache2/sites-enabled/*
This shows only active sites, check
sites-available if you have to migrate sites which are currently turned off, too.
The resulting list, if sanitized, can be piped on the shell and used with something like
dig +short, to easily check which domains are still running.
Check all the records, not just the
AAAA (quad-A is ipv4, single-A is ipv4) records, also MX and whatever is set.
If the exit code is non-zero, no dns anymore and less work for you.
Providing a script here would not help much, since you should know what you are doing here anyway and it would most likely not help you much.
In case the apache config is, lets say, 'adventurous', do
apache2ctl -S (Debian/Ubuntu) or
httpd -S to see which domains are hosted, and in which file these are defined.
Then search there for
If the webserver happens to have all vhosts defined in one huge file (which ist just... very not great), remove the configuration and place them into a separated file.
In Debian-based Linuces you can use
a2ensite <vhost-config-filename> /
a2dissite <vhost-config-filename> to enable/disable single websites easily.
On Redhat-based ones you create the symlinks to the configfolder apache is configured to load manually and delete them also by hand. (This isn't any different from what
All this only for the sites you want to migrate.
Of course, you can just comment out the information on your vhosts from the config, but just... don't.
For other webservers all this is different, of course, but you get the idea.
Refer to the website via its main link.
ServerName from above.)
But make sure to note all other aliases there, too.
ServerAlias from above.)
Since you can only migrate one site after another, this helps to keep track.
Write all this down, each alias in another row.
Maybe put the inactive ones into an extra column there, too.
Could be that these should be prolonged again, or were incorrectly set.
(I.e. it did not point to the webserver when you checked.)
Write the set TTL into the next column, along with the current date. (Usually TTL is 86400, which means 24 hours, which is exactly how long it will take until your change to 1800 seconds becomes finally active. If the TTL was longer than 86400 for whatever reason, note that into your list, too!)
After having created a list and checked which domains are currently active, set the default TTL time to 1800. (Just don't go below, 30 mins are short while you do the migration. Also the registrar might prefer you not to.)
If you have A LOT of websites that should go from one server to the next, try migrating and testing everything (via entries in the hosts file). Then switch the ip's of the servers with each other. That way no dns changes are needed (except if you have dead domains), because this shit can become tedious, too.
Nothing more here now, until i am motivated again to write more stuff up.
posted on 2014-10-30 19:53:49
.rpm files in debian (If god likes you, then they just may.), you have to convert them to
.deb formatted files.
alien is the weapon of choice.
# apt-get install alien
To convert and install:
alien <packagename>.rpm dpkg -i <packagename_converted>.deb
To convert and install in one step:
alien -i <packagename>.rpm
By default, the version number of the .rpm files will be incremented by one.
If you do not want this behaviour, you might try the
posted on 2014-08-26 16:40:50
When debugging SSH connections, or rather their connection establishment mishaps, check the logs:
Usually this does suffice.
If not, increase the Log Level in
View posts from 2017-09, 2017-08, 2017-07, 2017-05, 2017-04, 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10