bootstrap-vz-remote - program is creating Debian images to be run in cloud
environments like Amazons EC2, OpenStack, Google Cloud Compute and other which
are sharing API with those via remote servers.
Normally you'd use bootstrap-vz
to start a bootstrapping process. When
bootstrapping remotely simply use bootstrap-vz-remote
instead, it takes
the same arguments plus a few additional ones:
- --servers <path>: Path to a list of
build-servers (see build-servers.yml for more info)
- --name <name>: Selects a specific build-server
from the list of build-servers
- --release <release>: Restricts the
autoselection of build-servers to the ones with the specified release
Much like when bootstrapping directly, you can press Ctrl+C
at any time
to abort the bootstrapping process. The remote process will receive the
keyboard interrupt signal and begin cleaning up - pressing Ctrl+C
second time will abort that as well and kill the connection immediately.
Note that there is also a bootstrap-vz-server
, this file is not meant to
be invoked directly by the user, but is instead launched by bootstrap-vz on
the remote server when connecting to it.
For the remote bootstrapping procedure to work, you will need to install
bootstrap-vz as well as the sudo
command on the remote machine. Also
make sure that all the needed dependencies for bootstrapping your image are
Locally the pip package Pyro4
The file build-servers.yml
informs bootstrap-vz about the different build
servers you have at your disposal. In its simplest form you can just add your
own machine like this:
specifies how bootstrap-vz should connect to the build-server.
simply means that it will call the bootstrapping procedure
directly, no new process is spawned.
tells bootstrap-vz for which providers this machine is
capable of building images. With the exception of the EC2 provider, the
accepted values match the accepted provider names in the manifest. For EC2 you
can specify ec2-s3
the machine in question can bootstrap EBS backed images and should only be
used when the it is located on EC2. ec2-s3
signifies that the machine
is capable of bootstrapping S3 backed images.
Beyond being a string, the value of release
is not enforced in any way.
It's only current use is for bootstrap-vz-remote
where you can restrict
which build-server should be autoselected.
The other (and more interesting) setting for type
requires a few more configuration settings:
# remote settings below here
The last 5 settings specify how bootstrap-vz can connect to the remote
build-server. While the initial handshake is achieved through SSH,
bootstrap-vz mainly communicates with its counterpart through RPC (the
communication port is automatically forwarded through an SSH tunnel).
self explanatory (remote machine address, SSH port, login name and path to
private SSH key file).
refers to the aboved mentioned
executable. This is the command bootstrap-vz executes on the remote machine to
start the RPC server.
Be aware that there are a few limitations as to what bootstrap-vz is able to
deal with, regarding the remote machine setup (in time they may be fixed by a
- The login user must be able to execute sudo without a
- The private key file must be added to the ssh-agent before
invocation (alternatively it may not be password protected)
- The server must already be part of the known_hosts list
(bootstrap-vz uses ssh directly and cannot handle interactive
The build settings allow you to override specific manifest properties. This is
useful when for example the VirtualBox guest additions ISO is located at
on server 1, while server 2 has it at