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
|
// Copyright (C) 2015-2024 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at http://mozilla.org/MPL/2.0/.
/**
@page ctrlSocket Control Channel
@section ctrlSocketOverview Control Channel Overview
In many cases it is useful to manage certain aspects of the DHCP servers
while they are running. In Kea, this may be done via the Control Channel.
Control Channel allows an external entity (e.g. a tool run by a sysadmin
or a script) to issue commands to the server which can influence its
behavior or retrieve information from it. Several notable examples
envisioned are: reconfiguration, statistics retrieval and manipulation,
and shutdown.
Communication over Control Channel is conducted using JSON structures.
The supported communication channel is UNIX stream and HTTP/HTTPS sockets.
If configured, Kea will open a socket and will listen for any incoming
connections. A process connecting to this socket is expected to send JSON
commands structured as follows:
@code
{
"command": "foo",
"arguments": {
"param_foo": "value1",
"param_bar": "value2",
...
}
}
@endcode
- command - is the name of command to execute and is mandatory.
- arguments - contain a single parameter or a map or parameters
required to carry out the given command. The exact content and format is command specific.
The server will process the incoming command and then send a response of the form:
@code
{
"result": 0|1,
"text": "textual description",
"arguments": {
"argument1": "value1",
"argument2": "value2",
...
}
}
@endcode
- result - indicates the outcome of the command. A value of 0 means a success while
any non-zero value designates an error. Currently 1 is used as a generic error, but additional
error codes may be added in the future.
- text field - typically appears when result is non-zero and contains description of the error
encountered.
- arguments - is a map of additional data values returned by the server, specific to the
command issue. The map is always present, even if it contains no data values.
@section ctrlSocketClient Using UNIX Control Channel
Here are two examples of how to access the UNIX Control Channel:
1. Use socat tool, which is available in many Linux and BSD distributions.
See http://www.dest-unreach.org/socat/ for details. To use it:
@code
socat UNIX:/var/run/kea/kea4.sock -
@endcode
You then can type JSON commands and get responses (also in JSON format).
2. Here's an example C code that connects and gets a list of supported commands:
@code
// Copyright (C) 2015-2020 Internet Systems Consortium, Inc. ("ISC")
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at http://mozilla.org/MPL/2.0/.
#include <sys/socket.h>
#include <sys/un.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main(int argc, const char* argv[]) {
if (argc != 2) {
printf("Usage: %s socket_path\n", argv[0]);
return (1);
}
// Create UNIX stream socket.
int socket_fd;
if ((socket_fd = socket(AF_UNIX, SOCK_STREAM, 0)) < 0)
{
perror("Failed to create UNIX stream");
return (1);
}
// Specify the address to connect to (unix path)
struct sockaddr_un srv_addr;
memset(&srv_addr, 0, sizeof(struct sockaddr_un));
srv_addr.sun_family = AF_UNIX;
strcpy(srv_addr.sun_path, argv[1]);
socklen_t len = sizeof(srv_addr);
// Try to connect.
if (connect(socket_fd, (struct sockaddr*) &srv_addr, len) == -1) {
perror("Failed to connect");
return (1);
}
// Send a command to list all available commands.
char buf[1024];
sprintf(buf, "{ \"command\": \"list-commands\" }");
int bytes_sent = send(socket_fd, buf, strlen(buf), 0);
printf("%d bytes sent\n", bytes_sent);
// Receive a response (should be JSON formatted list of commands)
int bytes_rcvd = recv(socket_fd, buf, sizeof(buf), 0);
printf("%d bytes received: [%s]\n", bytes_rcvd, buf);
// Close the socket
close(socket_fd);
return 0;
}
@endcode
@section ctrlSocketImpl Control Channel Implementation
Control Channel is implemented in @ref isc::config::CommandMgr. It is a singleton
class that allows registration of callbacks that handle specific commands.
It internally supports a single command: @c list-commands that returns a list
of supported commands. This component is expected to be shared among all daemons.
There are 3 main methods that are expected to be used by developers:
- @ref isc::config::CommandMgr::registerCommand, which allows registration of
additional commands.
- @ref isc::config::CommandMgr::deregisterCommand, which allows removing previously
registered command.
- @ref isc::config::CommandMgr::processCommand, which allows handling specified
command.
Kea servers use @c CommandMgr to register handlers for various commands they
support natively. However, it is possible extend a set of supported commands
using hooks framework. See @ref hooksdgCommandHandlers how to implement support
for your own control commands in Kea.
@section unixCtrlSocketImpl UNIX Control Channel Implementation
UNIX Control Channel is implemented in @ref isc::config::UnixCommandMgr.
It is a singleton class providing two methods for managing control sockets.
They are not expected to be used directly.
- @ref isc::config::UnixCommandMgr::openCommandSocket that passes
structure defined in the configuration file. Currently only two
parameters are supported: socket-type (which must contain value
'unix') and socket-name (which contains unix path for the named
socket to be created).
- @ref isc::config::UnixCommandMgr::closeCommandSocket() - it is used
to close the socket.
@section ctrlSocketConnections Accepting connections
The @ref isc::config::UnixCommandMgr is implemented using boost ASIO and uses
asynchronous calls to accept new connections and receive commands from the
controlling clients. ASIO uses IO service object to run asynchronous calls.
Thus, before the server can use the @ref isc::config::UnixCommandMgr it must
provide it with a common instance of the @ref isc::asiolink::IOService
object using @ref isc::config::UnixCommandMgr::setIOService. The server's
main loop must contain calls to @ref isc::asiolink::IOService::run or
@ref isc::asiolink::IOService::poll or their variants to invoke Command
Manager's handlers as required for processing control requests.
@section ctrlSocketMTConsiderations Multi-Threading Consideration for Control Channel
The control channel utilities are not thread safe but they are used only
by the main thread so in most cases it does not matter. For instance
the assumption that only at most one command can be executed at a given
time can be done. Of course this has its limit: when the command changes
the configuration or is incompatible with a simultaneous packet
processing the multi-threading mode must be checked and service threads
stopped.
*/
|
