Migrating Servers

On occasion, you may want to move from one server to another. For example, you may be upgrading from a shared server to a cloud server. You can request a server migration at any time with the WebFaction control panel (Accounts ‣ Resize or migrate plan). You choose the kind and location of the destination server, as well as the migration path you want to use.

There are two migration methods. You can choose to let WebFaction migrate servers for you or manually migrate from one server to another yourself. Whichever way you choose, you are responsible for verifying that the migration was completed successfully.

If you have chosen to migrate servers yourself, there are a few steps and choices ahead of you. The process may look daunting, but it’s easier with a little bit of planning and attention to detail.

Migrating Manually

There are two different procedures for migrating from one server to another yourself. The Simple Migration Guide minimizes the number of steps used to migrate, but you may incur some downtime as you move. The Advanced Migration Guide minimizes the duration of downtime with a more complex procedure. Choose a procedure based on your downtime requirements and the level of complexity with which you’re comfortable.

As always, consider contacting the WebFaction support team if you’re not clear on some particular step. The support team will be happy to provide guidance and assistance through this process.

Simple Migration Guide

This simplified migration guide minimizes the number of steps to migrate from one server to another. If you do not need to maximize the availability of your sites or you are uncomfortable working with DNS changes and your system’s hosts file, use this procedure.

Create Users

The first step in moving to a new server is to create on the destination server the same users that appear on the origin server. For each user on the origin machine, create an equivalent user on the destination machine.

Create Applications

The next step is to recreate applications on the destination server. For each application on the origin server (as noted by the Machine column), create a new application with the same name on the destination server.

Note

Some applications, such as WordPress, may not permit two applications to share the same name. If you encounter this during your migration, create an application with a different name, but remember to use the alternate name when importing database records and creating website entries.

Copy Files

The next step is to copy files from the origin server to the destination server. rsync makes this easy.

  1. For each user on the origin server:
    1. Open an SSH session on the origin machine.
    2. Get a list of files to be copied. Enter rsync -nPaAz ~/ username@destination.webfaction.com:, where username is the current user name and destination is the name of the destination server, and press Enter. A list of files to be copied will appear; no files are copied at this time.
    3. Verify that the files to be copied are those you intended.
    4. Copy the files to the destination server. Enter rsync -PaAz ~/ username@destination.webfaction.com: (noting that the n switch has been omitted) and press Enter. The files will be copied. Depending on the number and size of the files to be copied, this process may take a few minutes to finish.
  2. If applicable, verify that the permissions for your extra users are correct by accessing files with the new extra users you would expect to have access to. If needed, grant access to your extra users.

Copy Crontabs

If you have configured or modified your users’ crontabs, the contents of your users’ crontabs must be copied from the origin server to the destination server. For each user:

  1. Open an SSH session on the origin server.
  2. Export the contents of the crontab to a file. Enter crontab -l > username_cron, where username is the name of the current user and press Enter. A file, username_cron, will be created in the current directory.
  3. Copy the file to the destination server. Enter scp username_cron username@destination.webfaction.com: and press Enter. The file is copied to the destination server.
  4. Close the SSH session.
  5. Open an SSH session on the destination server.
  6. Import the crontab. Enter crontab username_cron and press Enter.

Create Databases and Database Users

The next step is to recreate the databases and their users on the destination server.

Many application installers create a database automatically. If you have successfully recreated these applications, their databases and users do not need to be duplicated manually.

For all other databases and users, you must recreate each yourself. For each database on the origin server, create a new database on the destination server. For each database user on the origin server, create a new user and grant permissions. Be sure to use the same database names and usernames on the destination server as those on the origin server.

Copy Database Records

Once the databases are set up to receive the data from the origin server, it’s time to to export the data from the origin server and import that data to the databases on the destination server.

  1. Open an SSH session on the origin server.

  2. For each MySQL database on the origin server, dump the contents of the database to a file. Enter mysqldump -u username database -p > database.sql, where:

    • database is the name of the database
    • username is the name of a user that owns or has permission to use the database

    and press Enter. A dump file, database.sql, is created in the current directory.

  3. For each PostgreSQL database on the origin server, dump the contents of the database to a file. Enter pg_dump -U username -f database.sql database and press Enter. A dump file, database.sql is created in the current directory.

  4. Copy the dump files to the destination server. Enter scp ./*.sql username@destination.webfaction.com: and press Enter. All .sql files are copied to the destination server.

  5. Close the SSH session on the origin server.

  6. Open an SSH session on the destination server.

  7. For each MySQL database on the destination server, import the corresponding dump file. Enter mysql -u username -p -D database < database.sql and press Enter. The contents of the file are loaded into the specified database.

  8. For each PostgreSQL database on the destination server, import the corresponding dump file. Enter psql -U username database < database.sql and press Enter. The contents of the file are loaded into the specified database.

Edit Website Records

The next step is to modify your website entries to use the applications on the destination server.

  1. Log in to the control panel.
  2. Click Domains / websites ‣ Websites. The list of websites appears.
  3. Modify the site records. For each website entry on the origin server:
    1. Click the name of the website entry. The site’s details appear.
    2. In the Machine menu, click to select the destination server.
    3. For each application in the Contents section:
      1. Remove the origin server application. Click x. The application is removed from the list.
      2. Click Add an application ‣ Reuse an existing application. The Reuse an existing web app form appears.
      3. In the Application menu, click to select the destination server application. For example, if you removed my_wp - origin then click to select my_wp - destination.
      4. In the URL field, enter the same URL as the origin server application’s URL.
      5. Click the Save button.
    4. Click the Save button.

Finishing Touches

Now that you have verified your destination server is operating smoothly, it is time to make any last minute updates, and clean up.

  1. If needed, copy any new files or migrate any new data from the origin server to the destination server.
  2. Reply to your existing support ticket (or open a new ticket) to inform the support team that your migration is complete and you’re ready for your data to be deleted on the origin server.

Congratulations, you have successfully migrated from one server to another.

Advanced Migration Guide

This advanced version of the migration process minimizes downtime at the expense of added complexity. Use this procedure if you need to maximize the availability of your sites and applications and you are comfortable working with DNS changes and your system’s hosts file.

Create Users

The first step in moving to a new server is to create on the destination server the same users that appear on the origin server. For each user on the origin machine, create an equivalent user on the destination machine.

Create Applications

The next step is to recreate applications on the destination server. For each application on the origin server (as noted by the Machine column), create a new application with the same name on the destination server.

Note

Some applications, such as WordPress, may not permit two applications to share the same name. If you encounter this during your migration, create an application with a different name, but remember to use the alternate name when importing database records and creating website entries.

Copy Files

The next step is to copy files from the origin server to the destination server. rsync makes this easy.

  1. For each user on the origin server:
    1. Open an SSH session on the origin machine.
    2. Get a list of files to be copied. Enter rsync -nPaAz ~/ username@destination.webfaction.com:, where username is the current user name and destination is the name of the destination server, and press Enter. A list of files to be copied will appear; no files are copied at this time.
    3. Verify that the files to be copied are those you intended.
    4. Copy the files to the destination server. Enter rsync -PaAz ~/ username@destination.webfaction.com: (noting that the n switch has been omitted) and press Enter. The files will be copied. Depending on the number and size of the files to be copied, this process may take a few minutes to finish.
  2. If applicable, verify that the permissions for your extra users are correct by accessing files with the new extra users you would expect to have access to. If needed, grant access to your extra users

Copy Crontabs

If you have configured or modified your users’ crontabs, the contents of your users’ crontabs must be copied from the origin server to the destination server. For each user:

  1. Open an SSH session on the origin server.
  2. Export the contents of the crontab to a file. Enter crontab -l > username_cron, where username is the name of the current user and press Enter. A file, username_cron, will be created in the current directory.
  3. Copy the file to the destination server. Enter scp username_cron username@destination.webfaction.com: and press Enter. The file is copied to the destination server.
  4. Close the SSH session.
  5. Open an SSH session on the destination server.
  6. Import the crontab. Enter crontab username_cron and press Enter.

Create Databases and Database Users

The next step is to recreate the databases and their users on the destination server.

Many application installers create a database automatically. If you have successfully recreated these applications, their databases and users do not need to be duplicated manually.

For all other databases and users, you must recreate each yourself. For each database on the origin server, create a new database on the destination server. For each database user on the origin server, create a new user and grant permissions. Be sure to use the same database names and usernames on the destination server as those on the origin server.

Copy Database Records

Once the databases are set up to receive the data from the origin server, it’s time to to export the data from the origin server and import that data to the databases on the destination server.

  1. Open an SSH session on the origin server.

  2. For each MySQL database on the origin server, dump the contents of the database to a file. Enter mysqldump -u username database -p > database.sql, where:

    • database is the name of the database
    • username is the name of a user that owns or has permission to use the database

    and press Enter. A dump file, database.sql, is created in the current directory.

  3. For each PostgreSQL database on the origin server, dump the contents of the database to a file. Enter pg_dump -U username -f database.sql database and press Enter. A dump file, database.sql is created in the current directory.

  4. Copy the dump files to the destination server. Enter scp ./*.sql username@destination.webfaction.com: and press Enter. All .sql files are copied to the destination server.

  5. Close the SSH session on the origin server.

  6. Open an SSH session on the destination server.

  7. For each MySQL database on the destination server, import the corresponding dump file. Enter mysql -u username -p -D database < database.sql and press Enter. The contents of the file are loaded into the specified database.

  8. For each PostgreSQL database on the destination server, import the corresponding dump file. Enter psql -U username database < database.sql and press Enter. The contents of the file are loaded into the specified database.

Reconfigure Domains

Now it is time to create the environment to test the applications on your migrated server.

To create this environment, you must use the control panel to modify your domain name records such that the destination server will not be used to serve pages and data (at least not until they’ve been tested).

For each domain in use by the existing origin server websites, configure an A or AAAA record such that the IP address of the record is set to the IP address of the origin server.

Note

To find the IP address of the origin server:

  1. Log in to the WebFaction control panel.
  2. Click Account ‣ Services.
  3. Review the table’s IP address column.

Create Website Records

The next step is to recreate your website entries.

  1. Log in to the WebFaction control panel.
  2. Click Domains / websites ‣ Websites. The list of websites appears.
  3. For each website entry on the origin server, create a new website entry with the same settings, except for these differences:
    • in the Name field, enter a unique name;
    • in the Machine field, click to select the destination server;
    • each application added to the site must be the migrated application on the destination server. For example, if my_wp - origin were in use in the origin server’s website record, use my_wp - destination where destination and origin are the destination and origin servers, respectively.

Test Your Migrated Applications

Now it is time to verify that everything on the new server is working correctly. Because of the DNS changes made previously, you must reconfigure your computer to use the destination server instead of the origin server for each of your domains.

Warning

Always create a backup before modifying system files.

  1. Open your hosts file in a text editor. Different operating systems store this file in different locations:

    • Windows: %SystemRoot%\system32\drivers\etc\ (typically, c:\windows\system32\drivers\etc\)
    • Mac OS X: /private/etc/hosts/ or /etc/hosts/
    • Linux: /etc/hosts
  2. For each A and AAAA record you made previously, add this line to the file:

    ip example.com
    

    where ip is the IP address of the destination server (such as 192.0.2.5 or 2001:0db8:85a3:0000:0000:8a2e:0370:7334) and example.com is the domain for which you created the A or AAAA record.

  3. Save and close the file.

Now you can access your websites as they will appear on the destination server. Take the time to verify that each application works as you expect it to. If needed, make any necessary configuration changes to make your new applications work.

For example, you may need to update the port number used in conjunction with some application types, including all custom applications listening on a port. Other applications which require port number changes include:

  • mod_wsgi-based applications (such as Django) in their ~/webapps/app_name/apache2/httpd.conf files
  • Passenger-based applications (such as Rails and Redmine) in their ~/webapps/app_name/nginx/conf/nginx.conf files
  • Private MySQL instances in their ~/webapps/app_name/etc/my.cnf files
  • Private PostgreSQL instances in their ~/webapps/app_name/data/postgresql.conf files
  • Pyramid applications in their ~/webapps/app_name/development.ini files

Only when you are confident the applications on the destination server are working properly should you move on to the next phase of migration.

Warning

Once you’re finished testing, don’t forget to revert the changes made to your hosts file.

Direct Traffic to the New Server

Once you’ve verified that the sites on the destination server are working properly, you may begin directing traffic to the new server.

To direct incoming traffic to the destination server, you must use the control panel to modify your domain name records such that they point to the destination server, instead of the origin server. This is a modification of the domain configuration changes you made previously.

To modify your domain name records:

  1. Log in to the WebFaction control panel.
  2. Click Domains / websites ‣ Domains. The list of domains appears.
  3. For each domain:
    1. Click on the domain name. The domain’s settings appear.
    2. For each origin server IP address (in other words, for each IPv4 and IPv6 address, as applicable):
      1. Remove the origin server IP address. Click the - (minus) button.
      2. Click Add IP Address. A field appears.
      3. In the field, enter the destination server’s IP address.
    3. Click the Save button.

Incoming traffic is now directed to the destination server. To allow time for DNS servers to update their caches, wait 24 hours before continuing to the next step. To confirm that incoming traffic is limited to only the new server, review the origin server log files.

Delete Origin Server Websites

Once traffic has transitioned to the new server, it is safe to remove origin server website records. To remove the origin server website records:

  1. Log in to the WebFaction control panel.
  2. Click Domains / websites ‣ Websites. The list of websites appears.
  3. For each website hosted on the origin server:
    1. Click on the website’s name.
    2. Click the Delete button. A prompt, Are you sure you wish to delete the website?, appears.
    3. To delete the website, click the Yes, I’m sure button. To keep the website (for example, you selected the wrong website), click No, Cancel.

Once you have deleted all of the origin server websites, continue to the next step.

Remove DNS Records

Once you’ve removed the origin server websites, it’s safe to remove the A and AAAA records you made previously.

To remove the A and AAAA records:

  1. Log in to the WebFaction control panel.
  2. Click Domains / websites ‣ Domains. The list of domains appears.
  3. For each domain:
    1. Click on the domain name. The domain’s settings appear.
    2. In the Hosting section, click to select WebFaction.
    3. Click the Save button.

The A and AAAA records are removed.

Finishing Touches

Now that you’ve transitioned traffic to the destination server, it’s time to make any last minute updates and clean up.

  1. If needed, copy any new files or migrate any new data from the origin server to the destination server.
  2. Reply to your existing support ticket (or open a new ticket) to inform the support team that your migration is complete and you’re ready for your data to be deleted on the origin server.

Congratulations, you have successfully migrated from one server to another.

Migrating from a CentOS 6 Server to a CentOS 7 Server

If you’re migrating from a CentOS 6 server to a CentOS 7 server, please be aware of the following upgrade notes.

General

Many common applications, such as WordPress, Subversion, Static-only and Static/CGI/PHP applications, continue to work without any changes, but others may require changes to run on the newer server. The following sections contain details about specific software and applications.

In our testing, binaries compiled for CentOS 6 continue to work on CentOS 7. Some system libraries may have changed or have been removed, however. If you are running software that depends on such libraries, you may need to recompile on the destination server.

Private MySQL Instances

If you’re running a private MySQL instance, then changes between MySQL versions require that you run an upgrade command. To upgrade a private MySQL instance:

  1. Open an SSH session to your account on the destination server.
  2. Run the MySQL upgrade command. Enter mysql_upgrade --protocol=tcp -P port -v -u root -p, where port is the port number assigned to the private MySQL instance, and press Enter. A password prompt appears.
  3. Enter the password for the root user and press Enter. You can find the root user’s password in the application’s Extra info field in the control panel.

The database is upgraded.

Private PostgreSQL Instances

If you’re running a private PostgreSQL instance, then changes between PostgreSQL versions require that you complete several migration steps. Some steps must be completed on the origin server (prior to migration). The remaining steps must be completed on the destination server (after migration).

Before migration

Before beginning your migration, make a backup of your private PostgreSQL instance data:

  1. Find the origin server’s private PostgreSQL instance’s port number in the control panel.
  2. Open an SSH session to your account on the origin server.
  3. Enter /usr/pgsql-9.1/bin/pg_dumpall -h localhost -p port_number > $HOME/webapps/pgsql_app/dumps/dumpall.sql, where port_number is the port assigned to the origin server’s private PostgreSQL instance, and press Enter.

After migration

After migration, upgrade the private PostgreSQL instance’s configuration and reload your data:

  1. Open an SSH session to your account on the destination server.
  2. Update the PostgreSQL version in the instance’s bin/start and bin/stop scripts. Enter sed -i -e 's/9.1/9.4/' $HOME/webapps/pgsql_app/bin/start,stop and press Enter.
  3. Replace unix_socket_directory with unix_socket_directories in ~/webapps/pgsql_app/postgresql.conf. Enter sed -i -e 's/unix_socket_directory/unix_socket_directories/' $HOME/webapps/pgsql_app/data/postgresql.conf and press Enter.
  4. Rename the existing data directory. Enter mv $HOME/pgsql_app/data $HOME/pgsql_app/data.old and press Enter.
  5. Make a new data directory. Enter cut -d ':' -f 5 ~/.pgpass > ~/webapps/pgsql_app/pw && /usr/pgsql-9.4/bin/initdb -D $HOME/webapps/pgsql_app/data -E UTF8 --pwfile $HOME/webapps/pgsql_app/pw -A password && rm ~/webapps/pgsql_app/pw and press Enter.
  6. Copy the original configuration files from the old data directory to the new data directory. Enter cp $HOME/webapps/pgsql_app/data.old/*.conf $HOME/webapps/pgsql_app/data/ and press Enter.
  7. Find the destination server’s private PostgreSQL instance’s port number in the control panel.
  8. Update the port number in the configuration file. Enter sed -i -e 's/port = [0-9]+/port = port_number/g' $HOME/webapps/pgsql_app/data/postgresql.conf, where port_number is the port assigned to the destination server’s private PostgreSQL instance, and press Enter.
  9. Start the private PostgreSQL instance. Enter $HOME/webapps/pgsql_app/bin/start and press Enter.
  10. Import the dump file you created before the migration. Enter psql -h localhost -p port_number postgres < $HOME/webapps/pgsql_app/dumps/dumpall.sql and press Enter.

The private PostgreSQL instance and its data are migrated.

PHP

Versions of PHP prior to PHP 5.4 are neither supported nor installed on CentOS 7 servers. If you’re using PHP, then we recommend that you upgrade to a more recent version of PHP.

Before upgrading, please review the applicable PHP migration guides for your intended PHP version and any intermediate versions:

Other upgrade steps may be required by the PHP libraries or application you’re using. Please review their documentation for additional upgrade instructions.

To upgrade to a more recent version of PHP:

  1. Open an SSH session to your account.

  2. Switch to the PHP-based application’s directory. Enter cd $HOME/webapps/app/, where app is the name of your PHP-based application, and press Enter.

  3. Create a .htaccess file, if it does not already exist. Enter touch .htaccess and press Enter.

  4. Open the .htaccess file in a text editor.

  5. Add the following lines to switch to PHP 5.6:

    <FilesMatch \.php$>
        SetHandler php56-cgi
    </FilesMatch>
    

    Alternatively, you may substitute php56-cgi with php55-cgi for PHP 5.5 or php54-cgi for PHP 5.4.

  6. Save and close the file.

Python

Versions of Python prior to Python 2.5 are neither supported nor installed on CentOS 7 servers. If you’re using Python, then we recommend that you upgrade your applications to Python 2.7 or later to make it easier to migrate your applications and to enjoy the benefits of bug fixes and security releases.

Compiled Python extensions may not run after migration. Python on CentOS 7 servers is compiled with UCS-4 (UTF-32) instead of UCS-2 (UTF-16); they are not binary compatible. As a result, you may need to recompile extensions to Python. Typically, reinstalling libraries with such extensions (with pip or setup.py, for example) recompiles the binaries.

CentOS 7’s Python 2.6 does not support the deprecated standard library module bsddb. If you’re using Python 2.6 with the bsddb module, then we recommend that you upgrade to Python 2.7. If you’re unable to upgrade, then you can install the bsddb185 library as a substitute for the standard library’s bsddb module.

CentOS 7’s Python 2.5 does not support the deprecated standard library module bsddb. If you’re using Python 2.5 with the bsddb module, then we recommend that you upgrade to Python 2.7.

Ruby

Versions of Ruby prior to 1.9 are neither supported nor installed on CentOS 7 servers. If you’re using Ruby, then we recommend that you upgrade to a more recent version of Ruby.

Migrating from a CentOS 5 Server to a CentOS 7 Server

If you’re migrating from a CentOS 5 server to a CentOS 7 server, please be aware of the following upgrade notes.

General

Many common applications, such as WordPress, Subversion, Static-only and Static/CGI/PHP applications, continue to work without any changes, but others may require changes to run on the newer server. The following sections contain details about specific software and applications.

In our testing, most binaries compiled on a CentOS 5 server will not run on a CentOS 7 server. Additionally, some system libraries may have changed or have been removed. Typically, you must recompile binaries on the destination server.

Private MySQL Instances

If you’re running a private MySQL instance, then changes between MySQL versions require that you complete several migration steps. Some steps must be completed on the origin server (prior to migration). The remaining steps must be completed on the destination server (after migration).

Before migration

Before beginning your migration, update users’ password hashes to use a more secure algorithm:

  1. Find the origin server’s private MySQL instance’s port number in the control panel.

  2. Open an SSH session to your account on the origin server.

  3. Log in to private MySQL instance as the root user. Enter mysql -P <port_number -u root -p --protocol=tcp, where port_number is the port assigned to the origin server’s private MySQL instance, and press Enter. A password prompt appears.

  4. Enter the password for the root user and press Enter.

  5. Get a list of users to update. Enter select user, host from mysql.user where length(password)=16; and press Enter.

  6. For each user and host listed, enter set password for 'user'@'host' = password('password'); where:

    • user and host are a user name and hostname pair from the previous step and
    • password is the user’s password (you may use an existing or new password)

    and press Enter.

After migration

After migration, upgrade the private MySQL instance:

  1. Open an SSH session to your account on the destination server.
  2. Run the MySQL upgrade command. Enter mysql_upgrade --protocol=tcp -P port -v -u root -p, where port is the port number assigned to the private MySQL instance, and press Enter. A password prompt appears.
  3. Enter the password for the root user and press Enter. You can find the root user’s password in the application’s Extra info field in the control panel.

The database is migrated.

Private PostgreSQL Instances

If you’re running a private PostgreSQL instance, then changes between PostgreSQL versions require that you complete several migration steps. Some steps must be completed on the origin server (prior to migration). The remaining steps must be completed on the destination server (after migration).

Before migration

Before beginning your migration, make a backup of your private PostgreSQL instance data:

  1. Find the origin server’s private PostgreSQL instance’s port number in the control panel.
  2. Open an SSH session to your account on the origin server.
  3. Enter /usr/bin/pg_dumpall -h localhost -p port_number > $HOME/webapps/pgsql_app/dumps/dumpall.sql, where port_number is the port assigned to the origin server’s private PostgreSQL instance, and press Enter.

After migration

After migration, upgrade the private PostgreSQL instance’s configuration and reload your data:

  1. Open an SSH session to your account on the destination server.
  2. Update the PostgreSQL version in the instance’s bin/start and bin/stop scripts. Enter sed -i -e 's/\/usr/\/usr/pgsql-9.4/' $HOME/webapps/pgsql_app/bin/start,stop and press Enter.
  3. Replace unix_socket_directory with unix_socket_directories in ~/webapps/pgsql_app/postgresql.conf. Enter sed -i -e 's/unix_socket_directory/unix_socket_directories/' $HOME/webapps/pgsql_app/data/postgresql.conf and press Enter.
  4. Rename the existing data directory. Enter mv $HOME/pgsql_app/data $HOME/pgsql_app/data.old and press Enter.
  5. Make a new data directory. Enter cut -d ':' -f 5 ~/.pgpass > ~/webapps/pgsql_app/pw && /usr/pgsql-9.4/bin/initdb -D $HOME/webapps/pgsql_app/data -E UTF8 --pwfile $HOME/webapps/pgsql_app/pw -A password && rm ~/webapps/pgsql_app/pw and press Enter.
  6. Copy the original configuration files from the old data directory to the new data directory. Enter cp $HOME/webapps/pgsql_app/data.old/*.conf $HOME/webapps/pgsql_app/data/ and press Enter.
  7. Find the destination server’s private PostgreSQL instance’s port number in the control panel.
  8. Update the port number in the configuration file. Enter sed -i -e 's/port = [0-9]+/port = port_number/g' $HOME/webapps/pgsql_app/data/postgresql.conf, where port_number is the port assigned to the destination server’s private PostgreSQL instance, and press Enter.
  9. Start the private PostgreSQL instance. Enter $HOME/webapps/pgsql_app/bin/start and press Enter.
  10. Import the dump file you created before the migration. Enter psql -h localhost -p port_number postgres < $HOME/webapps/pgsql_app/dumps/dumpall.sql and press Enter.

The private PostgreSQL instance and its data are migrated.

Python

Versions of Python prior to Python 2.5 are neither supported nor installed on CentOS 7 servers. If you’re using Python, then we recommend that you upgrade your applications to Python 2.7 or later to make it easier to migrate your applications and to enjoy the benefits of bug fixes and security releases.

Compiled Python extensions may not run after migration. Python on CentOS 7 servers is compiled with UCS-4 (UTF-32) instead of UCS-2 (UTF-16); they are not binary compatible. As a result, you may need to recompile extensions to Python. Typically, reinstalling libraries with such extensions (with pip or setup.py, for example) recompiles the binaries.

CentOS 7’s Python 2.6 does not support the deprecated standard library module bsddb. If you’re using Python 2.6 with the bsddb module, then we recommend that you upgrade to Python 2.7. If you’re unable to upgrade, then you can install the bsddb185 library as a substitute for the standard library’s bsddb module.

CentOS 7’s Python 2.5 does not support the deprecated standard library module bsddb. If you’re using Python 2.5 with the bsddb module, then we recommend that you upgrade to Python 2.7.

Django

In addition to changes to Python on CentOS 7 servers, Django applications require a binary and libraries compiled for the destination server after migration (otherwise, an error while loading shared libraries error will occur). To finish a Django application migration:

  1. Create an additional Django application of the same version as the migrated application.
  2. Update the Django application’s binary and libraries.
    1. Open an SSH session to your account on the destination server.
    2. Copy the Apache HTTP Server binaries from the additional Django application to the migrated application. Enter cp $HOME/webapps/additional/apache2/bin/httpd* $HOME/webapps/migrated/apache2/bin/, where additional is the additional Django application and migrated is the migrated Django application, and press Enter.
    3. Copy the contents of the additional Django application’s modules directory to the migrated Django application’s modules directory. Enter cp $HOME/webapps/additional/apache2/modules/* $HOME/webapps/migrated/apache2/modules/ and press Enter.
    4. Restart the migrated Django application. Enter $HOME/webapps/migrated/apache2/bin/restart and press Enter.
  3. Verify that your Django application is now running properly.
  4. Remove the additional Django application.

Trac

Migrated Trac applications must be switched over to a newer version of Python for continued Subversion integration; otherwise, a Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn) error will occur. To finish migrating a Trac application to a CentOS 7 server:

  1. Modify the Trac application’s CGI file to use Python 2.6.
    1. Open $HOME/webapps/tracapp/cgi-bin/trac.cgi, where tracapp is the name of the Trac application, in a text editor.
    2. Change the first line of the file from #!/usr/local/bin/python2.4 to #!/usr/local/bin/python2.6.
    3. Save and close the file.
  2. Move the Trac application’s libraries the new required location.
    1. Open an SSH session to your account on the destination server.
    2. Remove the symbolic link to the Trac static assets. Enter rm $HOME/webapps/tracapp/htdocs and press Enter.
    3. Move the Trac libraries. Enter mv $HOME/webapps/tracapp/lib/python2.4 $HOME/webapps/tracapp/lib/python2.6 and press Enter
    4. Recreate the symbolic link to the Trac static assets. Enter ln -s $HOME/webapps/tracapp/lib/python2.6/Trac-0.12-py2.4.egg/trac/htdocs $HOME/webapps/tracapp/htdocs and press Enter.

PHP

PHP-based applications no longer need a symbolic link to a PHP binary nor certain .htaccess directives. For each PHP-based application:

  1. Open an SSH session to your account.

  2. Switch to the PHP-based application’s directory. Enter cd $HOME/webapps/migrated/, where migrated is the name of the PHP-based application, and press Enter.

  3. Open .htaccess in a text editor.

  4. Remove the lines that look like this:

    Action php56-cgi /php56.cgi
    AddHandler php56-cgi .php
    

    The exact lines vary according to the version of PHP (for example, php55-cgi for PHP 5.5).

  5. Save and close the file.

  6. Remove the symbolic link to the PHP binary that corresponds to the lines removed from the .htaccess file. For example, enter rm php56.cgi and press Enter.

Versions of PHP prior to PHP 5.4 are neither supported nor installed on CentOS 7 servers. If you’re using PHP, then we recommend that you upgrade to a more recent version of PHP.

Before upgrading, please review the applicable PHP migration guides for your intended PHP version and any intermediate versions:

Other upgrade steps may be required by the PHP libraries or application you’re using. Please review their documentation for additional upgrade instructions.

To upgrade to a more recent version of PHP:

  1. Open an SSH session to your account.

  2. Switch to the PHP-based application’s directory. Enter cd $HOME/webapps/app/, where app is the name of your PHP-based application, and press Enter.

  3. Create a .htaccess file, if it does not already exist. Enter touch .htaccess and press Enter.

  4. Open the .htaccess file in a text editor.

  5. Add the following lines to switch to PHP 5.6:

    <FilesMatch \.php$>
        SetHandler php56-cgi
    </FilesMatch>
    

    Alternatively, you may substitute php56-cgi with php55-cgi for PHP 5.5 or php54-cgi for PHP 5.4.

  6. Save and close the file.

If you’ve migrated from an old server (< web120 or < dweb61) then note that PHP on the new server is served via php-cgi as opposed to mod_php. This means that if you’re using directives such as “php_value ...” in some .htaccess files you will have to move these to a php.ini file.

You can find affected .htaccess files by running the following command in a SSH session: egrep -r --include .htaccess '(php_flag|php_value)' ~

More information is available in our PHP documentation.

Ruby

Versions of Ruby prior to 1.9 are neither supported nor installed on CentOS 7 servers. If you’re using Ruby, then we recommend that you upgrade to a more recent version of Ruby.

Rails

In addition to changes to Ruby on CentOS 7 servers, Rails applications require a binary and libraries compiled for the destination server after migration (otherwise, an error while loading shared libraries error will occur). To finish migrating a Rails application to a CentOS 7 server:

  1. Create an additional Rails application of the same version as the migrated application.
  2. Update the Rails application’s binary and libraries.
    1. Open an SSH session to your account on the destination server.
    2. Copy the nginx file from the additional Rails application to the migrated application. Enter cp $HOME/webapps/additional/nginx/sbin/nginx $HOME/webapps/migrated/nginx/sbin/nginx, where additional is the additional Rails application and migrated is the migrated Rails application and press Enter.
    3. Copy the contents of the additional Rails application’s gems directory to the migrated Rails application’s gems directory. Enter cp -R $HOME/webapps/additional/gems/* $HOME/webapps/migrated/gems/ and press Enter.
    4. Restart the migrated Rails application. Enter $HOME/webapps/migrated/bin/restart and press Enter.
  3. Verify that your Rails application is now running properly.
  4. Remove the additional Rails application.