This repository has been archived by the owner on Sep 23, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 82
/
README.txt
233 lines (149 loc) · 8.23 KB
/
README.txt
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
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
Workspace Cloud Client
----------------------
For more information, see:
http://www.nimbusproject.org/docs/current/clouds/cloudquickstart.html
And:
http://www.scienceclouds.org/
It is recommended that you follow the quickstarts at the web site, it usually
contains a better walkthrough.
For general notes on the capabilities and syntax of the cloud client, run
the help command:
$ ./bin/cloud-client.sh -h
You need to have Java installed in order to run this.
Security
--------
1. Obtain a credential.
The cloud administrator should have either provided you one or authorized your
preexisting credential.
The search path the cloud client uses is as follows:
A. props
If "nimbus.cert" and "nimbus.key" are in the properties file and point to
an unencrypted credential, they trump all. These are not present by default
but allow an advanced user to easily toggle between clouds by using the
--conf switch. If these values are relative paths, they will be resolved
relative to the configuration file they are read from.
B. proxy
If a normal proxy is present in the /tmp directory and is still valid, that
is used. This lets the cloud work with all existing certs, tooling,
MyProxy, etc.
Note: if you are using an encrypted key, such as the ones typically
provided by grid computing certificate authorities, you will need to
generate the proxy mentioned in this step. See the section below.
C. ~/.nimbus/
If ~/.nimbus/usercert.pem and ~/.nimbus/userkey.pem are present and the key
is unencrypted, use this. No proxy is required or created. This is what
most will use.
D. ~/.globus/
Same as #3 but with ~/.globus. The key still needs to be unencrypted.
2. Test the security setup.
$ ./bin/cloud-client.sh --security
3. If you already have a credential and have not given your DN to the cloud
administrators, do so sending the distinguished name printed after 'Identity'
Encrypted Keys and Proxy Credentials
------------------------------------
You might need to go the proxy credential route. For example, you were given
an encrypted certificate, this is typically found in grid computing.
If you do not have a proxy credential in place using some other tool (at for
example "/tmp/x509up_u1000" where "1000" is your unix account ID number), you
can use an embedded program to run grid-proxy-init like so:
$ ./bin/grid-proxy-init.sh
Note that grid-proxy-init does not follow the same search path as the cloud
client does when the cloud client is looking for unencrypted keys. Instead,
it only looks for "~/.globus/usercert.pem" and "~/.globus/userkey.pem".
But you can specify the paths exactly if that is not where you keep the cert
and encrypted key:
$ ./bin/grid-proxy-init.sh -cert /tmp/usercert.pem -key /tmp/userkey.pem
Issues? Try our mailing list and/or run:
$ ./bin/grid-proxy-init.sh -help
grid-proxy-init cannot find your credential's CA files? They are normally in
the "lib/certs" directory of the cloud client but you can override like so:
$ export NIMBUS_X509_TRUSTED_CERTS="/path/to/certificates_directory"
Configuring The Cloud
---------------------
If you received this tarball from the cloud administrator or cloud website,
you probably have the proper configuration file already.
Examine the "conf/cloud.properties" file.
You can put the correct settings there or override them all via commandline
(see --extrahelp). Or use different configuration files by using the --conf
option to specify an alternate.
Note that with clouds using Nimbus 2.5 and later, there is a repository ID and
symmetric key that you will need as well. This is a cloud specific, consult
your cloud documentation first. Again if you received this tarball from the
cloud administrator or cloud web application, you probably have the proper
configuration file already.
There is also a "conf/clouds/" directory that is used by the meta-cloud-client.
Each file in this directory contains the settings for a single cloud and is
identified by its filename. So the sample "conf/clouds/nimbus.properties" file
provides settings of the University of Chicago nimbus cloud and can be
referenced by the name "nimbus".
Uploading A Workspace To The Cloud
----------------------------------
1. Pick a local VM image to run. The image must conform in this manner:
a. DHCP broadcast at boot
b. Partition file that is mounted to /dev/sda1
(NOTE: on the Teraport cloud this may need to be /dev/xvda1 instead by default)
c. Running SSHd so that you can login. Your SSH key will be written
to /root/.ssh/authorized_keys on the VM before it is booted (see
below for how to pick which key this is).
2. You can transfer an image to the cloud and then run it in a single command.
Here is how to just do a transfer:
$ ./bin/cloud-client.sh --transfer --sourcefile /tmp/some_image
There are also --download (get an image in your personal directory) and
--delete (delete an image in your personal directory) options.
SSH Notes
---------
The SSH public key to configure is set in the "conf/cloud.properties" file.
This will set the policy for root SSH login inside the VM, the service will
deliver this file to the VM's "/root/.ssh/authorized_keys" file.
You can change what public key file is used by changing the relevant property.
Alternatively, you can override the configuration via commandline flag. You
can also override the other properties defined in that file by commandline
flag. These extra commandlines are listed in --extrahelp.
Note you can remove the property to disable the dynamic SSH policy installation
from happening at all.
Running A Workspace
-------------------
1. If you want to run the image you transferred in the previous section,
named 'some_image', here is how:
$ ./bin/cloud-client.sh --run --name some_image --hours 1
2. If you want to transfer the image to the cloud and run it in the same
command, you don't need the 'name' argument. In the absence of the
name argument, the image to run is deduced from the sourcefile argument.
$ ./bin/cloud-client.sh --transfer --sourcefile /tmp/some_image --run --hours 1
(The order of commandline flags does not matter, it will always transfer
before running.)
After sending a run command, the network address picked for the VM will be
displayed. Note that it will only be active once the VM is reported to be
running -- it just gets picked right away.
Because the public key file was installed to /root/.ssh/authorized_keys on
the VM before it boot (see last section), after it boots you should be able
to log in by running:
ssh root@example.com
... where "example.com" is the network address that was assigned to the
workspace and printed to your screen.
Workspace Handle
----------------
Note the short name of the workspace you created, e.g. "vm-009".
This corresponds to a directory created under the "history" directory. Files
from the instance creation are kept there, including log files and a handle
file (an "EPR" file, EPR stands for "endpoint reference"). The EPR allows you
to run subsequent management or query operations after creation. The following
sections discuss these.
See -h for more options (terminate, save).
Running a Multi-Cloud Workspace
-------------------------------
The meta-cloud-client supports running a cluster across multiple clouds with
a single command. It does not currently support any other operations, so you
will still need to use the cloud-client to upload and manage your images on
each cloud.
You must have a cloud properties file in place for each cloud you want to use.
This is described above. You must also provide a cloud deployment document that
describes which cloud you want each workspace to be deployed to. Sample
documents are available in the "samples" directory. Note that the cloud names
you use in this document must have corresponding cloud properties files in the
"conf/clouds" directory. So if you have references to <cloud>nimbus</cloud> and
<cloud>stratus</cloud>, you must have valid cloud configuration files
"conf/clouds/nimbus.properties" and "conf/clouds/stratus.properties".
A multi-cloud workspace can be run with the command:
$ ./bin/meta-cloud-client.sh --run --cluster cluster.xml \
--deploy deploy.xml --hours 1