Provided by: bootstrap-vz_0.9.11+20180121git-1_all bug


       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 a 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 installed.

       Locally the pip package Pyro4 is needed.


       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:

            type: local
            can_bootstrap: [virtualbox]
            release: jessie
            build_settings: {}

       type specifies how bootstrap-vz should connect to the build-server.   local  simply  means
       that it will call the bootstrapping procedure directly, no new process is spawned.

       can_bootstrap  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 and/or ec2-ebs.  ec2-ebs
       specifies that 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

   Remote settings
       The other (and more interesting) setting for type  is  ssh,  which  requires  a  few  more
       configuration settings:

            type: ssh
              - virtualbox
              - ec2-s3
            release: wheezy
            # remote settings below here
            port: 2222
            username: admin
            keyfile: path_to_private_key_file
            server_bin: /root/bootstrap/bootstrap-vz-server

       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).  address, port, username and keyfile are hopefully self  explanatory  (remote
       machine address, SSH port, login name and path to private SSH key file).

       server_bin  refers  to  the  aboved  mentioned bootstrap-vz-server 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  benevolent

       · The login user must be able to execute sudo without a password

       · 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 prompts)

   Build settings
       The build settings allow you to override specific manifest  properties.   This  is  useful
       when    for    example    the    VirtualBox    guest   additions   ISO   is   located   at
       /root/guest_additions.iso on server 1, while server 2 has it at /root/images/vbox.iso.

            type: local
              - virtualbox
              - ec2-s3
            release: jessie
              guest_additions: /root/images/VBoxGuestAdditions.iso
                port: 3142
                access-key: AFAKEACCESSKEYFORAWS
                secret-key: thes3cr3tkeyf0ryourawsaccount/FS4d8Qdva
                certificate: /root/manifests/cert.pem
                private-key: /root/manifests/pk.pem
                user-id: 1234-1234-1234
              s3-region: eu-west-1

                                         August 19, 2015                   BOOTSTRAP-VZ-REMOTE(1)