forked from OverC/meta-overc
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.runtime
195 lines (133 loc) · 5.38 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
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.
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 [--peer] [--nested] <name>
start (launch) a container (dom0 only):
--peer (default)
--nested
<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 restart <name> # (dom0 only):
restart container <name>. A graceful shutdown and relaunch will be
performed.
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