libknot 3.4.3__tar.gz → 3.4.4__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
libknot-3.4.4/PKG-INFO ADDED
@@ -0,0 +1,357 @@
1
+ Metadata-Version: 2.1
2
+ Name: libknot
3
+ Version: 3.4.4
4
+ Summary: Python bindings for libknot
5
+ Home-page: https://gitlab.nic.cz/knot/knot-dns/-/tree/master/python/libknot
6
+ Author: CZ.NIC, z.s.p.o.
7
+ Author-email: "CZ.NIC, z.s.p.o." <knot-dns@labs.nic.cz>
8
+ License: GPL-3.0
9
+ Project-URL: Documentation, https://www.knot-dns.cz/documentation
10
+ Project-URL: Issues, https://gitlab.nic.cz/knot/knot-dns/-/issues
11
+ Project-URL: Source, https://gitlab.nic.cz/knot/knot-dns/-/tree/master/python/libknot
12
+ Classifier: Development Status :: 5 - Production/Stable
13
+ Classifier: Intended Audience :: Developers
14
+ Classifier: Intended Audience :: System Administrators
15
+ Classifier: License :: OSI Approved :: GNU General Public License v3 (GPLv3)
16
+ Classifier: Programming Language :: Python :: 3
17
+ Classifier: Topic :: Internet :: Name Service (DNS)
18
+ Classifier: Topic :: Software Development :: Libraries
19
+ Classifier: Topic :: System :: Systems Administration
20
+ Requires-Python: >=3.5
21
+ Description-Content-Type: text/markdown
22
+
23
+ # Libknot API in Python
24
+
25
+ A Python interface for managing the Knot DNS daemon.
26
+
27
+ # Table of contents
28
+
29
+ * [Introduction](#introduction)
30
+ * [Control module](#control-module)
31
+ + [Protocol reference](#kctl-proto)
32
+ + [Commands reference](#kctl-cmds)
33
+ + [Usage](#control-usage)
34
+ + [Examples](#control-examples)
35
+ * [Probe module](#probe-module)
36
+ + [Probe usage](#probe-usage)
37
+ + [Probe examples](#probe-examples)
38
+ * [Dname module](#dname-module)
39
+ + [Dname usage](#dname-usage)
40
+ + [Dname examples](#dname-examples)
41
+
42
+ ## Introduction<a id="introduction"></a>
43
+
44
+ If the shared `libknot.so` library isn't available in the library search path, it's
45
+ necessary to load the library first, e.g.:
46
+
47
+ ```python3
48
+ import libknot
49
+ libknot.Knot("/usr/lib/libknot.so")
50
+ ```
51
+
52
+ ## Control module<a id="control-module"></a>
53
+
54
+ Using this module it's possible to create scripts for efficient tasks that
55
+ would require complex shell scripts with multiple calls of `knotc`. For
56
+ communication with the daemon it uses the same mechanism as the `knotc` utility,
57
+ i.e. communication via a Unix socket.
58
+
59
+ The module API is stored in `libknot.control`.
60
+
61
+ ### Protocol overview<a id="kctl-proto"></a>
62
+
63
+ Connections are supposed to be short-lived, because maintaining a passive
64
+ connection is costly for the server. Therefore the expected usage of the control
65
+ interface is to always open a new connection on demand, then close it once it's
66
+ not immediately needed.
67
+
68
+ Messages are composed of units. These are of four types the identifiers of
69
+ which are defined in `libknot.control.KnotCtlType`:
70
+
71
+ | Type | Description | IO action |
72
+ | ------- | ---------------------------------------------------------- | --------- |
73
+ | `END` | Signals intent to terminate connection. | flush |
74
+ | `DATA` | Holds various information - see about data sections below. | cache |
75
+ | `EXTRA` | Additional data. | cache |
76
+ | `BLOCK` | End of data block. | flush |
77
+
78
+ `DATA` and `EXTRA` units aren't immediately sent, rather they're buffered and
79
+ then sent along with the next `END` or `BLOCK` unit.
80
+
81
+ A unit can optionaly hold data, though this is only meaningful for the `DATA`
82
+ and `EXTRA` types. The data consists of several sections of which usually only
83
+ a few at a time will be present. For example when a unit issuing a `stats`
84
+ command is sent, there is no reason for it to contain an `ID` section.
85
+
86
+ The data section identifiers are defined in `libknot.control.KnotCtlDataIdx`:
87
+
88
+ | Section name | `send_block()` arg name | Description |
89
+ | ------------ | ----------------------- | ------------------------------------------------------ |
90
+ | `COMMAND` | cmd | Command name. |
91
+ | `FLAGS` | flags | Command flags. |
92
+ | `ERROR` | *(n/a)* | Error message. Only sent by the server. |
93
+ | `SECTION` | section | Configuration section name. |
94
+ | `ITEM` | item | Configuration item name. |
95
+ | `ID` | identifier | Configuration item identifier. |
96
+ | `ZONE` | zone | Zone name. |
97
+ | `OWNER` | owner | Zone record owner |
98
+ | `TTL` | ttl | Zone record TTL. |
99
+ | `TYPE` | rtype | Zone record type name. |
100
+ | `DATA` | data | Configuration item/zone record data. |
101
+ | `FILTERS` | filters | Command options or filters for output data processing. |
102
+
103
+ ### Commands reference<a id="kctl-cmds"></a>
104
+
105
+ The following is a reference for the low-level control API. In case you're unsure
106
+ of the commands' semantics, please consult the
107
+ <a href="https://www.knot-dns.cz/docs/latest/singlehtml/index.html#actions">knotc documentation</a>.
108
+
109
+ A concise notation is used for command synopsis:
110
+
111
+ ```
112
+ # command "cmd-name" accepts section of type SECTION_NAME and optionally
113
+ # another section of type OPT_SECTION
114
+ cmd-name(SECTION_NAME, [OPT_SECTION])
115
+
116
+ [OPT_SECTION="literal value"], # Optional section with fixed expected value.
117
+ [SECTION1, SECTION2] # Sections must be present together or not at all.
118
+ [SECTION1, [SECTION2]] # SECTION2 may only appear if SECTION1 is present.
119
+ SECTION_NAME="option1"|"option2" # Either one or the other literal may be used.
120
+ SECTION_NAME={"asdf"} # Any subset of characters may be used.
121
+ ```
122
+
123
+ The `B` flag always represents an option to execute in blocking mode.
124
+
125
+ When listing the filters a command accepts, the letter which is passed into
126
+ `FILTERS` will be boldened. Like this: zone**f**ile
127
+
128
+ #### Server
129
+
130
+ * `status([TYPE="cert-key"|"configure"|"version"|"workers"])`
131
+ * `stop()`
132
+ * `reload()`
133
+ * `stats([SECTION, [ITEM]], [FLAGS="F"])`
134
+ + `SECTION` stores the module, `ITEM` stores the counter
135
+ + the `F` flag specifies to include 0 counters in server's response
136
+
137
+ #### Zone events
138
+
139
+ The following commands apply to all zones if `ZONE` is left empty.
140
+
141
+ * `zone-status([ZONE], [FILTERS={"rstefc"}])`
142
+ + filters: **r**ole, **s**erial, **t**ransaction, **e**vents, **f**reeze, **c**atalog <!-- , **u**nixtime -->
143
+ * `zone-reload([ZONE], [FLAGS={"BF"}])`
144
+ + the `F` flag commands to also reload modules
145
+ * `zone-refresh([ZONE], [FLAGS="B"])`
146
+ * `zone-retransfer([ZONE], [FLAGS="B"])`
147
+ * `zone-notify([ZONE], [FLAGS="B"])`
148
+ * `zone-flush([ZONE], [FILTERS="d", DATA], [FLAGS={"FB"}])`
149
+ + the output**d**ir filter commands that zone(s) be flushed to path stored in the `DATA` section
150
+ + the `F` flag is required if zonefile synchronization is disabled
151
+ * `zone-backup([ZONE], [FILTERS={"dzjtkocqZJTKOCQ"}, [DATA]], [FLAGS="B"])`
152
+ + filters
153
+ - the backup**d**ir filter commands that backups be made to path stored in the `DATA` section
154
+ - **z**onefile, **j**ournal, **t**imers, **k**aspdb, keys**o**nly, **c**atalog, **q**uic
155
+ - negative counterparts (eg. no**Z**onefile) are symmetrical and capitalized
156
+ + the `F` flag allows for an existing backupdir to be overwritten
157
+ * `zone-restore` *analogous to `zone-backup`*
158
+ * `zone-sign([ZONE], [FLAGS="B"])`
159
+ * `zone-validate([ZONE], [FLAGS="B"])`
160
+ * `zone-keys-load([ZONE], [FLAGS="B"])`
161
+ * `zone-key-rollover([ZONE], TYPE="ksk"|"zsk", [FLAGS="B"])`
162
+ * `zone-ksk-submitted([ZONE], [FLAGS="B"])`
163
+ * `zone-freeze([ZONE], [FLAGS="B"])`
164
+ * `zone-thaw([ZONE], [FLAGS="B"])`
165
+ * `zone-xfr-freeze([ZONE], [FLAGS="B"])`
166
+ * `zone-xfr-thaw([ZONE], [FLAGS="B"])`
167
+
168
+ #### Zone editing
169
+
170
+ Use `@` as `OWNER` if you want to denote `ZONE` itself as the owner.
171
+
172
+ * `zone-read([ZONE], [OWNER], [TYPE])`
173
+ + if `ZONE` is left empty all zones are read
174
+ * `zone-begin(ZONE, [FILTERS="b"])`
175
+ + filters: **b**enevolent
176
+ * `zone-commit([ZONE])`
177
+ * `zone-abort([ZONE])`
178
+ * `zone-diff([ZONE])`
179
+ * `zone-get([ZONE], [OWNER], [TYPE])`
180
+ * `zone-set([ZONE], OWNER, [TTL], TYPE, DATA)`
181
+ * `zone-unset([ZONE], OWNER, [TYPE, [DATA]])`
182
+ * `zone-purge([ZONE], [FILTERS={ocejktf}], [FLAGS="B"])`
183
+ + filters: **o**rphan, **c**atalog, **e**xpire, **j**ournal, **k**aspdb, **t**imers, zone**f**ile
184
+ * `zone-stats([ZONE], [SECTION, [ITEM]], [FLAGS="F"])`
185
+ + `SECTION` stores the module, `ITEM` stores the counter
186
+ + the `F` flag specifies to include 0 counters in server's response
187
+
188
+ #### Configuration
189
+
190
+ For the following commands:
191
+
192
+ * `SECTION` holds the configuration section name (eg. `template`)
193
+ * `ID` holds the configuration id (eg. `default`)
194
+ * `ITEM` holds the configuration item name (eg. `storage`)
195
+
196
+ <!-- hacky comment to separate markdown lists -->
197
+
198
+ * `conf-list([SECTION, [ID], [ITEM]], [FILTERS="z"|{"st"}])`
199
+ + filters:
200
+ - **z**one: list all zone names, including those from the catalog
201
+ - li**s**t: list configuration section items instead of its identifiers
202
+ - **t**ransaction: If a transaction is open (`conf-begin`) queries the
203
+ transaction's configuration schema instead of the server's
204
+ * `conf-read([SECTION, [ID], [ITEM]])`
205
+ * `conf-begin()`
206
+ * `conf-commit()`
207
+ * `conf-abort()`
208
+ * `conf-diff([SECTION, [ID], [ITEM]])`
209
+ * `conf-get([SECTION, [ID], [ITEM]])`
210
+ * `conf-set(SECTION, ID, ITEM, [DATA])`
211
+ * `conf-unset([SECTION, [ID], [ITEM], [DATA]])`
212
+ + `DATA` may only be meaningfully specified if the preceding sections are as well
213
+
214
+ ### Control usage<a id="control-usage"></a>
215
+
216
+ The module usage consists of several steps:
217
+
218
+ * Initialization and connection to the daemon control socket.
219
+ * One or more control operations. An operation is called by sending a command
220
+ with optional data to the daemon. The operation result has to be received
221
+ afterwards.
222
+ * Closing the connection and deinitialization.
223
+
224
+ #### Sending
225
+
226
+ There are two methods on the `KnotCtl` class which send data to the socket.
227
+
228
+ `KnotCtl.send(KnotCtlType, KnotCtlData)` is the more rudimentary one. It only
229
+ sends the section identifier along with its data, if any are provided. When
230
+ using this function users must beware of the different characteristics
231
+ regarding buffering of different unit types.
232
+
233
+ `KnotCtl.send_block(...)` is more convenient in that it always flushes by
234
+ sending a `BLOCK` unit. Otherwise the two methods are functionally equivalent.
235
+
236
+ ### Control examples<a id="control-examples"></a>
237
+
238
+ ```python3
239
+ import json
240
+ import libknot.control
241
+
242
+ # Initialization
243
+ ctl = libknot.control.KnotCtl()
244
+ ctl.connect("/var/run/knot/knot.sock")
245
+ ctl.set_timeout(60)
246
+
247
+ try:
248
+ # Operation without parameters
249
+ ctl.send_block(cmd="conf-begin")
250
+ resp = ctl.receive_block()
251
+
252
+ # Operation with parameters
253
+ ctl.send_block(cmd="conf-set", section="zone", item="domain", data="test")
254
+ resp = ctl.receive_block()
255
+
256
+ ctl.send_block(cmd="conf-commit")
257
+ resp = ctl.receive_block()
258
+
259
+ # Operation with a result displayed in JSON format
260
+ ctl.send_block(cmd="conf-read", section="zone", item="domain")
261
+ resp = ctl.receive_block()
262
+ print(json.dumps(resp, indent=4))
263
+ except libknot.control.KnotCtlError as exc:
264
+ # Print libknot error
265
+ print(exc)
266
+ finally:
267
+ # Deinitialization
268
+ ctl.send(libknot.control.KnotCtlType.END)
269
+ ctl.close()
270
+ ```
271
+
272
+ ```python3
273
+ # List configured zones (including catalog member ones)
274
+ ctl.send_block(cmd="conf-list", filters="z")
275
+ resp = ctl.receive_block()
276
+ for zone in resp['zone']:
277
+ print(zone)
278
+ ```
279
+
280
+ ```python3
281
+ # Print expirations as unixtime for all secondary zones
282
+ ctl.send_block(cmd="zone-status", filters="u")
283
+ resp = ctl.receive_block()
284
+ for zone in resp:
285
+ if resp[zone]["role"] == "master":
286
+ continue
287
+
288
+ expiration = resp[zone]["expiration"]
289
+ if expiration == "-":
290
+ print("Zone %s not loaded" % zone)
291
+ else:
292
+ print("Zone %s expires at %s" % (zone, resp[zone]["expiration"]))
293
+ ```
294
+
295
+ ## Probe module<a id="probe module"></a>
296
+
297
+ Using this module it's possible to receive traffic data from a running daemon with
298
+ active probe module.
299
+
300
+ The module API is stored in `libknot.probe`.
301
+
302
+ ### Probe usage<a id="probe-usage"></a>
303
+
304
+ The module usage consists of several steps:
305
+
306
+ * Initialization of one or more probe channels
307
+ * Periodical receiving of data units from the channels and data processing
308
+
309
+ ### Probe examples<a id="probe-examples"></a>
310
+
311
+ ```python3
312
+ import libknot.probe
313
+
314
+ # Initialization of the first probe channel stored in `/run/knot`
315
+ probe = libknot.probe.KnotProbe("/run/knot", 1)
316
+
317
+ # Array for storing up to 8 data units
318
+ data = libknot.probe.KnotProbeDataArray(8)
319
+ while (True):
320
+ # Receiving data units with timeout of 1000 ms
321
+ if probe.consume(data, 1000) > 0:
322
+ # Printing received data units in the default format
323
+ for item in data:
324
+ print(item)
325
+ ```
326
+
327
+ ## Dname module<a id="dname-module"></a>
328
+
329
+ This module provides a few dname-related operations.
330
+
331
+ The module API is stored in `libknot.dname`.
332
+
333
+ ### Dname usage<a id="dname-usage"></a>
334
+
335
+ The dname object is initialized from a string with textual dname.
336
+ Then the dname can be reformatted to wire format or back to textual format.
337
+
338
+ ### Dname examples<a id="dname-examples"></a>
339
+
340
+ ```python3
341
+ import libknot.dname
342
+
343
+ dname1 = libknot.dname.KnotDname("knot-dns.cz")
344
+ print("%s: wire: %s size: %u" % (dname1.str(), dname1.wire(), dname1.size()))
345
+
346
+ dname2 = libknot.dname.KnotDname("e\\120ample.c\om.")
347
+ print("%s: wire: %s size: %u" % (dname2.str(), dname2.wire(), dname2.size()))
348
+
349
+ dname3 = libknot.dname.KnotDname(dname_wire=b'\x02cz\x00')
350
+ print("%s: wire: %s size: %u" % (dname3.str(), dname3.wire(), dname3.size()))
351
+ ```
352
+
353
+ ```bash
354
+ knot-dns.cz.: wire: b'\x08knot-dns\x02cz\x00' size: 13
355
+ example.com.: wire: b'\x07example\x03com\x00' size: 13
356
+ cz.: wire: b'\x02cz\x00' size: 4
357
+ ```
@@ -0,0 +1,335 @@
1
+ # Libknot API in Python
2
+
3
+ A Python interface for managing the Knot DNS daemon.
4
+
5
+ # Table of contents
6
+
7
+ * [Introduction](#introduction)
8
+ * [Control module](#control-module)
9
+ + [Protocol reference](#kctl-proto)
10
+ + [Commands reference](#kctl-cmds)
11
+ + [Usage](#control-usage)
12
+ + [Examples](#control-examples)
13
+ * [Probe module](#probe-module)
14
+ + [Probe usage](#probe-usage)
15
+ + [Probe examples](#probe-examples)
16
+ * [Dname module](#dname-module)
17
+ + [Dname usage](#dname-usage)
18
+ + [Dname examples](#dname-examples)
19
+
20
+ ## Introduction<a id="introduction"></a>
21
+
22
+ If the shared `libknot.so` library isn't available in the library search path, it's
23
+ necessary to load the library first, e.g.:
24
+
25
+ ```python3
26
+ import libknot
27
+ libknot.Knot("/usr/lib/libknot.so")
28
+ ```
29
+
30
+ ## Control module<a id="control-module"></a>
31
+
32
+ Using this module it's possible to create scripts for efficient tasks that
33
+ would require complex shell scripts with multiple calls of `knotc`. For
34
+ communication with the daemon it uses the same mechanism as the `knotc` utility,
35
+ i.e. communication via a Unix socket.
36
+
37
+ The module API is stored in `libknot.control`.
38
+
39
+ ### Protocol overview<a id="kctl-proto"></a>
40
+
41
+ Connections are supposed to be short-lived, because maintaining a passive
42
+ connection is costly for the server. Therefore the expected usage of the control
43
+ interface is to always open a new connection on demand, then close it once it's
44
+ not immediately needed.
45
+
46
+ Messages are composed of units. These are of four types the identifiers of
47
+ which are defined in `libknot.control.KnotCtlType`:
48
+
49
+ | Type | Description | IO action |
50
+ | ------- | ---------------------------------------------------------- | --------- |
51
+ | `END` | Signals intent to terminate connection. | flush |
52
+ | `DATA` | Holds various information - see about data sections below. | cache |
53
+ | `EXTRA` | Additional data. | cache |
54
+ | `BLOCK` | End of data block. | flush |
55
+
56
+ `DATA` and `EXTRA` units aren't immediately sent, rather they're buffered and
57
+ then sent along with the next `END` or `BLOCK` unit.
58
+
59
+ A unit can optionaly hold data, though this is only meaningful for the `DATA`
60
+ and `EXTRA` types. The data consists of several sections of which usually only
61
+ a few at a time will be present. For example when a unit issuing a `stats`
62
+ command is sent, there is no reason for it to contain an `ID` section.
63
+
64
+ The data section identifiers are defined in `libknot.control.KnotCtlDataIdx`:
65
+
66
+ | Section name | `send_block()` arg name | Description |
67
+ | ------------ | ----------------------- | ------------------------------------------------------ |
68
+ | `COMMAND` | cmd | Command name. |
69
+ | `FLAGS` | flags | Command flags. |
70
+ | `ERROR` | *(n/a)* | Error message. Only sent by the server. |
71
+ | `SECTION` | section | Configuration section name. |
72
+ | `ITEM` | item | Configuration item name. |
73
+ | `ID` | identifier | Configuration item identifier. |
74
+ | `ZONE` | zone | Zone name. |
75
+ | `OWNER` | owner | Zone record owner |
76
+ | `TTL` | ttl | Zone record TTL. |
77
+ | `TYPE` | rtype | Zone record type name. |
78
+ | `DATA` | data | Configuration item/zone record data. |
79
+ | `FILTERS` | filters | Command options or filters for output data processing. |
80
+
81
+ ### Commands reference<a id="kctl-cmds"></a>
82
+
83
+ The following is a reference for the low-level control API. In case you're unsure
84
+ of the commands' semantics, please consult the
85
+ <a href="https://www.knot-dns.cz/docs/latest/singlehtml/index.html#actions">knotc documentation</a>.
86
+
87
+ A concise notation is used for command synopsis:
88
+
89
+ ```
90
+ # command "cmd-name" accepts section of type SECTION_NAME and optionally
91
+ # another section of type OPT_SECTION
92
+ cmd-name(SECTION_NAME, [OPT_SECTION])
93
+
94
+ [OPT_SECTION="literal value"], # Optional section with fixed expected value.
95
+ [SECTION1, SECTION2] # Sections must be present together or not at all.
96
+ [SECTION1, [SECTION2]] # SECTION2 may only appear if SECTION1 is present.
97
+ SECTION_NAME="option1"|"option2" # Either one or the other literal may be used.
98
+ SECTION_NAME={"asdf"} # Any subset of characters may be used.
99
+ ```
100
+
101
+ The `B` flag always represents an option to execute in blocking mode.
102
+
103
+ When listing the filters a command accepts, the letter which is passed into
104
+ `FILTERS` will be boldened. Like this: zone**f**ile
105
+
106
+ #### Server
107
+
108
+ * `status([TYPE="cert-key"|"configure"|"version"|"workers"])`
109
+ * `stop()`
110
+ * `reload()`
111
+ * `stats([SECTION, [ITEM]], [FLAGS="F"])`
112
+ + `SECTION` stores the module, `ITEM` stores the counter
113
+ + the `F` flag specifies to include 0 counters in server's response
114
+
115
+ #### Zone events
116
+
117
+ The following commands apply to all zones if `ZONE` is left empty.
118
+
119
+ * `zone-status([ZONE], [FILTERS={"rstefc"}])`
120
+ + filters: **r**ole, **s**erial, **t**ransaction, **e**vents, **f**reeze, **c**atalog <!-- , **u**nixtime -->
121
+ * `zone-reload([ZONE], [FLAGS={"BF"}])`
122
+ + the `F` flag commands to also reload modules
123
+ * `zone-refresh([ZONE], [FLAGS="B"])`
124
+ * `zone-retransfer([ZONE], [FLAGS="B"])`
125
+ * `zone-notify([ZONE], [FLAGS="B"])`
126
+ * `zone-flush([ZONE], [FILTERS="d", DATA], [FLAGS={"FB"}])`
127
+ + the output**d**ir filter commands that zone(s) be flushed to path stored in the `DATA` section
128
+ + the `F` flag is required if zonefile synchronization is disabled
129
+ * `zone-backup([ZONE], [FILTERS={"dzjtkocqZJTKOCQ"}, [DATA]], [FLAGS="B"])`
130
+ + filters
131
+ - the backup**d**ir filter commands that backups be made to path stored in the `DATA` section
132
+ - **z**onefile, **j**ournal, **t**imers, **k**aspdb, keys**o**nly, **c**atalog, **q**uic
133
+ - negative counterparts (eg. no**Z**onefile) are symmetrical and capitalized
134
+ + the `F` flag allows for an existing backupdir to be overwritten
135
+ * `zone-restore` *analogous to `zone-backup`*
136
+ * `zone-sign([ZONE], [FLAGS="B"])`
137
+ * `zone-validate([ZONE], [FLAGS="B"])`
138
+ * `zone-keys-load([ZONE], [FLAGS="B"])`
139
+ * `zone-key-rollover([ZONE], TYPE="ksk"|"zsk", [FLAGS="B"])`
140
+ * `zone-ksk-submitted([ZONE], [FLAGS="B"])`
141
+ * `zone-freeze([ZONE], [FLAGS="B"])`
142
+ * `zone-thaw([ZONE], [FLAGS="B"])`
143
+ * `zone-xfr-freeze([ZONE], [FLAGS="B"])`
144
+ * `zone-xfr-thaw([ZONE], [FLAGS="B"])`
145
+
146
+ #### Zone editing
147
+
148
+ Use `@` as `OWNER` if you want to denote `ZONE` itself as the owner.
149
+
150
+ * `zone-read([ZONE], [OWNER], [TYPE])`
151
+ + if `ZONE` is left empty all zones are read
152
+ * `zone-begin(ZONE, [FILTERS="b"])`
153
+ + filters: **b**enevolent
154
+ * `zone-commit([ZONE])`
155
+ * `zone-abort([ZONE])`
156
+ * `zone-diff([ZONE])`
157
+ * `zone-get([ZONE], [OWNER], [TYPE])`
158
+ * `zone-set([ZONE], OWNER, [TTL], TYPE, DATA)`
159
+ * `zone-unset([ZONE], OWNER, [TYPE, [DATA]])`
160
+ * `zone-purge([ZONE], [FILTERS={ocejktf}], [FLAGS="B"])`
161
+ + filters: **o**rphan, **c**atalog, **e**xpire, **j**ournal, **k**aspdb, **t**imers, zone**f**ile
162
+ * `zone-stats([ZONE], [SECTION, [ITEM]], [FLAGS="F"])`
163
+ + `SECTION` stores the module, `ITEM` stores the counter
164
+ + the `F` flag specifies to include 0 counters in server's response
165
+
166
+ #### Configuration
167
+
168
+ For the following commands:
169
+
170
+ * `SECTION` holds the configuration section name (eg. `template`)
171
+ * `ID` holds the configuration id (eg. `default`)
172
+ * `ITEM` holds the configuration item name (eg. `storage`)
173
+
174
+ <!-- hacky comment to separate markdown lists -->
175
+
176
+ * `conf-list([SECTION, [ID], [ITEM]], [FILTERS="z"|{"st"}])`
177
+ + filters:
178
+ - **z**one: list all zone names, including those from the catalog
179
+ - li**s**t: list configuration section items instead of its identifiers
180
+ - **t**ransaction: If a transaction is open (`conf-begin`) queries the
181
+ transaction's configuration schema instead of the server's
182
+ * `conf-read([SECTION, [ID], [ITEM]])`
183
+ * `conf-begin()`
184
+ * `conf-commit()`
185
+ * `conf-abort()`
186
+ * `conf-diff([SECTION, [ID], [ITEM]])`
187
+ * `conf-get([SECTION, [ID], [ITEM]])`
188
+ * `conf-set(SECTION, ID, ITEM, [DATA])`
189
+ * `conf-unset([SECTION, [ID], [ITEM], [DATA]])`
190
+ + `DATA` may only be meaningfully specified if the preceding sections are as well
191
+
192
+ ### Control usage<a id="control-usage"></a>
193
+
194
+ The module usage consists of several steps:
195
+
196
+ * Initialization and connection to the daemon control socket.
197
+ * One or more control operations. An operation is called by sending a command
198
+ with optional data to the daemon. The operation result has to be received
199
+ afterwards.
200
+ * Closing the connection and deinitialization.
201
+
202
+ #### Sending
203
+
204
+ There are two methods on the `KnotCtl` class which send data to the socket.
205
+
206
+ `KnotCtl.send(KnotCtlType, KnotCtlData)` is the more rudimentary one. It only
207
+ sends the section identifier along with its data, if any are provided. When
208
+ using this function users must beware of the different characteristics
209
+ regarding buffering of different unit types.
210
+
211
+ `KnotCtl.send_block(...)` is more convenient in that it always flushes by
212
+ sending a `BLOCK` unit. Otherwise the two methods are functionally equivalent.
213
+
214
+ ### Control examples<a id="control-examples"></a>
215
+
216
+ ```python3
217
+ import json
218
+ import libknot.control
219
+
220
+ # Initialization
221
+ ctl = libknot.control.KnotCtl()
222
+ ctl.connect("/var/run/knot/knot.sock")
223
+ ctl.set_timeout(60)
224
+
225
+ try:
226
+ # Operation without parameters
227
+ ctl.send_block(cmd="conf-begin")
228
+ resp = ctl.receive_block()
229
+
230
+ # Operation with parameters
231
+ ctl.send_block(cmd="conf-set", section="zone", item="domain", data="test")
232
+ resp = ctl.receive_block()
233
+
234
+ ctl.send_block(cmd="conf-commit")
235
+ resp = ctl.receive_block()
236
+
237
+ # Operation with a result displayed in JSON format
238
+ ctl.send_block(cmd="conf-read", section="zone", item="domain")
239
+ resp = ctl.receive_block()
240
+ print(json.dumps(resp, indent=4))
241
+ except libknot.control.KnotCtlError as exc:
242
+ # Print libknot error
243
+ print(exc)
244
+ finally:
245
+ # Deinitialization
246
+ ctl.send(libknot.control.KnotCtlType.END)
247
+ ctl.close()
248
+ ```
249
+
250
+ ```python3
251
+ # List configured zones (including catalog member ones)
252
+ ctl.send_block(cmd="conf-list", filters="z")
253
+ resp = ctl.receive_block()
254
+ for zone in resp['zone']:
255
+ print(zone)
256
+ ```
257
+
258
+ ```python3
259
+ # Print expirations as unixtime for all secondary zones
260
+ ctl.send_block(cmd="zone-status", filters="u")
261
+ resp = ctl.receive_block()
262
+ for zone in resp:
263
+ if resp[zone]["role"] == "master":
264
+ continue
265
+
266
+ expiration = resp[zone]["expiration"]
267
+ if expiration == "-":
268
+ print("Zone %s not loaded" % zone)
269
+ else:
270
+ print("Zone %s expires at %s" % (zone, resp[zone]["expiration"]))
271
+ ```
272
+
273
+ ## Probe module<a id="probe module"></a>
274
+
275
+ Using this module it's possible to receive traffic data from a running daemon with
276
+ active probe module.
277
+
278
+ The module API is stored in `libknot.probe`.
279
+
280
+ ### Probe usage<a id="probe-usage"></a>
281
+
282
+ The module usage consists of several steps:
283
+
284
+ * Initialization of one or more probe channels
285
+ * Periodical receiving of data units from the channels and data processing
286
+
287
+ ### Probe examples<a id="probe-examples"></a>
288
+
289
+ ```python3
290
+ import libknot.probe
291
+
292
+ # Initialization of the first probe channel stored in `/run/knot`
293
+ probe = libknot.probe.KnotProbe("/run/knot", 1)
294
+
295
+ # Array for storing up to 8 data units
296
+ data = libknot.probe.KnotProbeDataArray(8)
297
+ while (True):
298
+ # Receiving data units with timeout of 1000 ms
299
+ if probe.consume(data, 1000) > 0:
300
+ # Printing received data units in the default format
301
+ for item in data:
302
+ print(item)
303
+ ```
304
+
305
+ ## Dname module<a id="dname-module"></a>
306
+
307
+ This module provides a few dname-related operations.
308
+
309
+ The module API is stored in `libknot.dname`.
310
+
311
+ ### Dname usage<a id="dname-usage"></a>
312
+
313
+ The dname object is initialized from a string with textual dname.
314
+ Then the dname can be reformatted to wire format or back to textual format.
315
+
316
+ ### Dname examples<a id="dname-examples"></a>
317
+
318
+ ```python3
319
+ import libknot.dname
320
+
321
+ dname1 = libknot.dname.KnotDname("knot-dns.cz")
322
+ print("%s: wire: %s size: %u" % (dname1.str(), dname1.wire(), dname1.size()))
323
+
324
+ dname2 = libknot.dname.KnotDname("e\\120ample.c\om.")
325
+ print("%s: wire: %s size: %u" % (dname2.str(), dname2.wire(), dname2.size()))
326
+
327
+ dname3 = libknot.dname.KnotDname(dname_wire=b'\x02cz\x00')
328
+ print("%s: wire: %s size: %u" % (dname3.str(), dname3.wire(), dname3.size()))
329
+ ```
330
+
331
+ ```bash
332
+ knot-dns.cz.: wire: b'\x08knot-dns\x02cz\x00' size: 13
333
+ example.com.: wire: b'\x07example\x03com\x00' size: 13
334
+ cz.: wire: b'\x02cz\x00' size: 4
335
+ ```