-
Notifications
You must be signed in to change notification settings - Fork 28
/
README.runtime
237 lines (164 loc) · 7.31 KB
/
README.runtime
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
234
235
236
OverC runtime
=============
Depending on the selected cubes, the user/application developer runtime varies.
Generally speaking, if either cube-desktop or cube-server have been selected the user
is presented with a enterprise-like, fully featured runtime that is suitable
for development or application deployment.
This includes common tasks such as: package additions, upgrades, local
development, desktop + utilities, etc.
cube management
===============
As described by the system overview in the README documentation, an OverC
platform is composed of multiple cubes. These cubes can be collectively,
or individually, managed and updated.
console
-------
Console access is available through several mechanisms:
- ssh: when installing a cube, the extraction utilities tests for avahi
capabilities. If present, the cube is configured to broadcast
its services though avahi. Standard ssh login restrictions apply,
and there are no restrictions on inter-cube logins (outside of
a working network).
Notes:
- avahi can be used to browse and locate active cubes.
- the hostname of each cube is used + the cube name in the
format of: cube-<build date>-<cube name>. If the hostname
or avahi configuration is changed, these defaults no longer
apply.
- vt: The assignments of VTs to cubes are specified in the configuration files
described in the README documentation. For example:
HDINSTALL_CONTAINERS="${ARTIFACTS_DIR}/cube-dom0-genericx86-64.tar.bz2:vty=2 \
${ARTIFACTS_DIR}/cube-server-genericx86-64.tar.bz2:vty=3 \
${ARTIFACTS_DIR}/cube-desktop-genericx86-64.tar.bz2:vty=4"
Once booted, this system would have dom0 on VT2, cube-server on VT3 and cube-desktop
on VT4.
- inter-cube pipes: For situations where a network is not available, and physical
access to VTs is not possible, OverC provides inter-cube pipe
based console access.
Since this capability requires a cube-cmd-server running on the
target cube, it is only available from user/application cubes
to dom0.
Standard authentication through 'login' is used to authenticate
access to dom0.
Once on dom0, console access can then be granted to any running
cube in the system by entering the proper namespace.
Access to both types of consoles is provided via the 'cube-console'
utility.
Networking
----------
Networking for the platform is initially configured/controlled by the installer, but
is subsequently managed at runtime via configuration values associated with a given
installer.
essential: Has a persistent veth pair which will usually have one endpoint
moved to a VRF namespace and added to the system switch
cube*: pflask configures and manages the networking of cubes via hooks and
cube-cfg values
*: all other containers are OCI format, and hence are managed via runc + hooks
and the same cube-cfg variables as cube*
While the networking configuration can vary, there are some constant/known values
to ensure minimal connectivity:
- network prime: The network prime container manages the physical device and
hence external network connectivity for the platform. Any
container can be the network prime, but dom0 or a cube-* are
typically used, since they are known quantities.
The network prime also hosts dhcp and DNS services for all
other containers. Hence why it must be a fully functional
container (and a known quantity).
- internal network: containers are all connected via 192.168.42.x connected
to an OVS instance. virtual ethernet devices are created
for each container, receive a dhcp address (by default)
and route through the netprime for services
- 192.168.42.1 : is always the network prime
- 192.168.42.2 : is always essential
- 192.168.42.3 : is always dom0
- 192.168.42.4 : is always the vrf
- if dom0 is the net prime, it is both 42.1 and 42.3
access examples:
----------------
ssh:
# cube-desktop terminal:
% uname -a | cut -d' ' -f2
cube-01-12-15-cube-desktop
# connect to dom0
% ssh root@cube-01-12-15-dom0.local
# connect to cube-server
% ssh root@cube-01-12-14-cube-server.local
console:
Consoles are accessed through standard VT switching mechanisms, such as
<ctrl>-<alt>-f1 (for cube-essential), <ctrl>-<alt>-f2 (for dom0), etc, depending
on the configuration (as described above).
inter-container pipes:
# find the valid console tarets:
% cube-ctl list
# cube-desktop -> dom0
% cube-console dom0
<login with dom0 credentials>
# cube-desktop -> cube-server, fails with an [ERROR] message, since cube-server is
# not a valid inter-container target
% cube-console cube-server
ERROR: cube is not allowed direct console access. log into dom0 first.
# dom0 -> cube-server (after logging into dom0), no prompt, since this is
# an admin -> namespace entry
% cube-console cube-server
bash-4.3#
utilities
========
OverC provides utilities for manipulating, querying and managing cubes.
Administrative commands are only allowed on dom0, and if issues from
a non-control cube, an error is returned.
cube-console:
-------------
Provides authenticated console access from user/application cubes to
dom0, and namespace based consoles from dom0 to application cubes.
Available targets can be found via: cube-ctl list
cube-ctl:
---------
cube-ctl <options> <cmd>
commands (and options):
cube-ctl start [-f] [-i] [-a] [auto=<name>] [<name>]
start (launch) a container (dom0 only):
-f: Start container in foreground on current tty
-i: Start interactive container console in foreground on current tty.
-a: attach container console just prior to start on current tty.
--auto=<name>: start containers with autostart set to <name>
<name>: name of the container to be launched
cube-ctl stop <name>
stop a container (dom0 only):
<name>: name of the container to be stoped
cube-ctl status
cube-ctl list
show the status (list) of known containers
cube-ctl <target>:<command> # (dom0 only):
execute command <command> against a named target. Either a container
name should be specified, or "host" for a native command.
cube-ctl info <name> # (dom0 only):
display detailed information about container <name>
cube-ctl rename <name> <new_name> # (dom0 only):
cube-ctl mv <name> <new_name> # (dom0 only):
rename container <name> to <new_name>.
Examples:
% cube-ctl cube-server:cat /etc/hostname
cube-02-12-15-cube-server
% cube-ctl info cube-server
Name: cube-server
State: RUNNING
PID: 3896
IP: 10.0.2.18
CPU use: 0.50 seconds
Memory use: 7.71 MiB
KMem use: 0 bytes
Link: vethO5HPB1
TX bytes: 243.02 KiB
RX bytes: 423.81 KiB
Total bytes: 666.83 KiB
% cube-ctl host:uname -a
Linux cube-02-12-15 4.2.0-cube #1 SMP Thu Nov 26 00:48:14 EST 2015 x86_64 GNU/Linux
% cube-ctl cube-invalid:ls /etc
Error, container cube-invalid does not exist.
% cube-ctl stop cube-server
% cube-ctl info cube-server
Name: cube-server
State: STOPPED
% cube-ctl start cube-server
% cube-ctl cube-server:uptime
21:38:29 up 3:21, 0 users, load average: 0.00, 0.01, 0.05