1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
.\" (C) Copyright 2014, Anders Ingemann
.\" (C) Copyright 2015 Marcin Kulisz (kuLa) <debian@kulisz.net>,
.
.nr rst2man-indent-level 0
.
.de1 rstReportMargin
\\$1 \\n[an-margin]
level \\n[rst2man-indent-level]
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
-
\\n[rst2man-indent0]
\\n[rst2man-indent1]
\\n[rst2man-indent2]
..
.de1 INDENT
.\" .rstReportMargin pre:
. RS \\$1
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
. nr rst2man-indent-level +1
.\" .rstReportMargin post:
..
.de UNINDENT
. RE
.\" indent \\n[an-margin]
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
.nr rst2man-indent-level -1
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.TH BOOTSTRAP-VZ-REMOTE 1 "August 19, 2015"
.SH NAME
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.
.SH BOOTSTRAP-VZ-REMOTE
.sp
Normally you\(aqd use \fBbootstrap\-vz\fP to start a bootstrapping process.
When bootstrapping remotely simply use \fBbootstrap\-vz\-remote\fP instead,
it takes the same arguments plus a few additional ones:
.INDENT 0.0
.IP \(bu 2
\fB\-\-servers <path>\fP: Path to a list of build\-servers
(see \fI\%build\-servers.yml\fP for more info)
.IP \(bu 2
\fB\-\-name <name>\fP: Selects a specific build\-server from the list
of build\-servers
.IP \(bu 2
\fB\-\-release <release>\fP: Restricts the autoselection of build\-servers
to the ones with the specified release
.UNINDENT
.sp
Much like when bootstrapping directly, you can press \fBCtrl+C\fP at any time
to abort the bootstrapping process.
The remote process will receive the keyboard interrupt signal
and begin cleaning up \- pressing \fBCtrl+C\fP a second time will abort that as
well and kill the connection immediately.
.sp
Note that there is also a \fBbootstrap\-vz\-server\fP, 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.
.SH DEPENDENCIES
.sp
For the remote bootstrapping procedure to work, you will need to install
bootstrap\-vz as well as the \fBsudo\fP command on the remote machine.
Also make sure that all the needed dependencies for bootstrapping your image
are installed.
.sp
Locally the pip package \fI\%Pyro4\fP is needed.
.SH BUILD-SERVERS.YML
.sp
The file \fBbuild\-servers.yml\fP 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:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
local:
type: local
can_bootstrap: [virtualbox]
release: jessie
build_settings: {}
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
\fBtype\fP specifies how bootstrap\-vz should connect to the build\-server.
\fBlocal\fP simply means that it will call the bootstrapping procedure directly,
no new process is spawned.
.sp
\fBcan_bootstrap\fP 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 \fBec2\-s3\fP and/or \fBec2\-ebs\fP\&.
\fBec2\-ebs\fP specifies that the machine in question can bootstrap EBS backed
images and should only be used when the it is located on EC2.
\fBec2\-s3\fP signifies that the machine is capable of bootstrapping S3 backed
images.
.sp
Beyond being a string, the value of \fBrelease\fP is not enforced in any way.
It\(aqs only current use is for \fBbootstrap\-vz\-remote\fP where you can restrict
which build\-server should be autoselected.
.SS Remote settings
.sp
The other (and more interesting) setting for \fBtype\fP is \fBssh\fP,
which requires a few more configuration settings:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
local_vm:
type: ssh
can_bootstrap:
\- virtualbox
\- ec2\-s3
release: wheezy
# remote settings below here
address: 127.0.0.1
port: 2222
username: admin
keyfile: path_to_private_key_file
server_bin: /root/bootstrap/bootstrap\-vz\-server
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
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).
\fBaddress\fP, \fBport\fP, \fBusername\fP and \fBkeyfile\fP are hopefully
self explanatory (remote machine address, SSH port, login name and path to
private SSH key file).
.sp
\fBserver_bin\fP refers to the \fI\%aboved mentioned\fP
bootstrap\-vz\-server executable. This is the command bootstrap\-vz executes
on the remote machine to start the RPC server.
.sp
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 contributor):
.INDENT 0.0
.IP \(bu 2
The login user must be able to execute sudo without a password
.IP \(bu 2
The private key file must be added to the ssh\-agent before invocation
(alternatively it may not be password protected)
.IP \(bu 2
The server must already be part of the known_hosts list
(bootstrap\-vz uses \fBssh\fP directly and cannot handle interactive prompts)
.UNINDENT
.SS Build settings
.sp
The build settings allow you to override specific manifest properties.
This is useful when for example the VirtualBox guest additions ISO is located
at \fB/root/guest_additions.iso\fP on server 1, while server 2 has it at
\fB/root/images/vbox.iso\fP\&.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
local:
type: local
can_bootstrap:
\- virtualbox
\- ec2\-s3
release: jessie
build_settings:
guest_additions: /root/images/VBoxGuestAdditions.iso
apt_proxy:
address: 127.0.0.1
port: 3142
ec2\-credentials:
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
|
