Files
hackacad/docs/chapters/migration.rst
2025-09-23 18:51:04 +02:00

108 lines
3.6 KiB
ReStructuredText
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Migration
=========
Bastille
--------
Bastille supports migrations to a remote system using the ``migrate`` subcommand.
Prerequisites
^^^^^^^^^^^^^
There are a couple of things that need to be in place before running the
``migrate`` command.
First, you must have bastille configured both locally and remotely to use the
same filesystem configuration. ZFS on both, or UFS on both.
Second, you must create a user on the remote system that will be used to migrate
the jail. The user must be able to log in via SSH using either key-based
authentication, or password based authentication.
The user also needs ``sudo`` permissions on the remote system. This user should
then be given as the ``USER`` arg in the ``migrate`` command.
If you don't want to use ``sudo``, we support using ``doas`` as the super-user
command. Simply set ``--doas`` as one of the options when running the ``migrate`` command.
If you are using key-based auth, the keys should be stored in the default
location at ``$HOME/.ssh/id_rsa``, where ``$HOME`` is the users home directory.
This is the default location for ssh keys, and where Bastille will try to load
them from.
If you want to use password based authentication, simply run
``bastille migrate -p TARGET USER@HOST``. This will prompt you to enter the
password for the remote system, which Bastille will then use during the migration
process.
Migration
^^^^^^^^^
To migrate a jail (or multiple jails) we can simply run
``bastille migrate TARGET USER@HOST``. This will export the jail(s), send them
to the remote system, and import them.
The ``migrate`` sub-command includes the ``-a|--auto`` option, which will
auto-stop the old jail, migrate it, and attempt to start the migrated jail on
the remote system after importing it. See the warning below about auto-starting
the migrated jail.
WARNING: Every system is unique, has different interfaces, bridges, and network
configurations. It is possible, with the right configuration, for jails to start
and work normally. But for some systems, it will be necessary to edit the
``jail.conf`` file of the migrated jail to get it working properly.
Using ``-l|--live`` mode (ZFS only) will leave the local jail running, and the
remote jail stopped.
Using ``-a|--auto`` mode will stop the local jail, and start the remote jail.
Using the ``-l|--live`` and ``-a|--auto`` options together will migrate the jail
while it is running, then stop the local jail, and start the remote jail.
You can optionally set ``-d|--destroy`` to have Bastille destroy the old jail on
completion.
You can also set ``-b|--backup`` to retain the archives remotely. They will be
copied into ``${bastille_backupsdir}``.
iocage
------
Stop the running jail and export it:
.. code-block:: shell
iocage stop jailname
iocage export jailname
Move the backup files (.zip and .sha256) into Bastille backup dir (default:
/usr/local/bastille/backups/):
.. code-block:: shell
mv /iocage/images/jailname_$(date +%F).* /usr/local/bastille/backups/
for remote systems you can use rsync:
.. code-block:: shell
rsync -avh /iocage/images/jailname_$(date +%F).* root@10.0.1.10:/usr/local/bastille/backups/
Import the iocage backup file (use zip file name)
.. code-block:: shell
bastille import jailname_$(date +%F).zip
Bastille will attempt to configure your interface and IP from the
``config.json`` file, but if you have issues you can configure it manually.
.. code-block:: shell
bastille edit jailname
ip4.addr = bastille0|192.168.0.1/24;
You can use your primary network interface instead of the virtual ``bastille0``
interface as well if you know what youre doing.