Skip to content
Permalink
Browse files

Add docs/MIGRATE.txt to document the new magical xboa features

  • Loading branch information...
omega8cc committed Mar 8, 2015
1 parent a5d1e70 commit eac1f3d0b16c171b8f62668ad2fb6b3c45027c76
Showing with 92 additions and 1 deletion.
  1. +91 −0 docs/MIGRATE.txt
  2. +1 −1 docs/REMOTE.txt
@@ -0,0 +1,91 @@

@=> How to migrate all sites between remote BOA servers and Octopus instances

While docs/REMOTE.txt provides a how-to for per-site migration between
remote Octopus instances, it depends on some assumptions, namely:

1. Remote Octopus instance must already exist
2. Remote Octopus instance must use the same system username
3. You need to either add proxy manually or hurry to update DNS
4. There is no batch mode

New BOA tool (xboa), which is expected to mature into more sophisticated
Swiss Army Knife for BOA, resolves all those problems, very easily.

The only requirement is that the remote BOA server should be installed
with the same release/version. No Octopus instance is needed on the target
system prior to migration.

It's a very safe and reliable (used in production) method when you need to:

1. Upgrade to a newer major OS version w/o the fear that things will totally
explode when running the system upgrade 'in place', like in this example:
https://github.com/omega8cc/boa/issues/627

2. Move to a different provider without any visible interruption to your
hosted sites visitors, especially when you have so many sites, so
manual procedure is not an option.

3. Just change the machine powering your BOA, magically, on the fly.

@=> The steps you need to follow are listed below.

The 'source-host' is a placeholder for the source system FQDN hostname.
The 'target-host' is a placeholder for the target system FQDN hostname.
The 'source-ip' is a placeholder for the source system IP addresss.
The 'target-ip' is a placeholder for the target system IP addresss.

While it is really easy when you have some experience with the procedure,
we don't recommend to use it on any live system without prior practicing
a bit on a test VPS instances.

Still scared? We can help! Let us know via: https://omega8.cc/sales

@=> On the target-host
echo "source-ip # Legacy Proxy" >> /etc/csf/csf.allow
echo "source-ip # Legacy Proxy" >> /etc/csf/csf.ignore
csf -q

@=> On the source-host
xboa pre-mig source-host

@=> On the target-host
xboa pre-mig source-host

@=> On the source-host
### test connection to target
ssh root@target-ip
exit
### transfer shared files
xboa transfer shared target-ip
### enable site_readonly globally
cp -af /data/conf/global.inc /data/conf/global.inc.bak
echo >> /data/conf/global.inc
echo "\$conf['site_readonly'] = 1;" >> /data/conf/global.inc
echo >> /data/conf/global.inc
grep site_readonly /data/conf/global.inc

@=> On the source-host
xboa create o1 target-ip
xboa export o1 target-ip
xboa transfer o1 target-ip

@=> On the target-host
service cron stop
(then wait 2 minutes)

@=> On the source-host
### sync shared files again
xboa transfer shared target-ip

@=> On the target-host
ln -sf /bin/websh /bin/sh
ls -la /bin/sh
xboa import o1 target-ip
service nginx reload
xboa post-mig

@=> On the source-host
xboa proxy o1 target-ip
service nginx reload
xboa post-mig
@@ -1,5 +1,5 @@

### How to migrate sites between remote Aegir instances
### How to migrate single sites between remote Aegir instances
#
# This is detailed how-to for remote_import Provision extension
# and hosting_remote_import module included by default in every

0 comments on commit eac1f3d

Please sign in to comment.
You can’t perform that action at this time.