1ovsdb-client(1) Open vSwitch Manual ovsdb-client(1)
2
3
4
6 ovsdb-client - command-line interface to ovsdb-server(1)
7
9 Server-Level Commands:
10 ovsdb-client [options] list-dbs [server]
11
12 Database Schema Commands:
13 ovsdb-client [options] get-schema [server] [database]
14 ovsdb-client [options] list-tables [server] [database]
15 ovsdb-client [options] list-columns [server] [database] [table]
16
17 Database Version Management Commands:
18 ovsdb-client [options] convert [server] schema
19 ovsdb-client [options] needs-conversion [server] schema
20 ovsdb-client [options] get-schema-version [server] [database]
21
22 Data Management Commands:
23 ovsdb-client [options] transact [server] transaction
24 ovsdb-client [options] query [server] transaction
25 ovsdb-client [options] dump [server] [database] [table [col‐
26 umn...]]
27 ovsdb-client [options] backup [server] [database] > snapshot
28 ovsdb-client [options] [--force] restore [server] [database] <
29 snapshot
30 ovsdb-client [options] monitor [server] [database] table [col‐
31 umn[,column]...]...
32 ovsdb-client [options] monitor [server] [database] ALL
33 ovsdb-client [options] monitor-cond [server] [database] condi‐
34 tions table [column[,column]...]...
35 ovsdb-client [options] monitor-cond-since [server] [database]
36 [last-id] conditions table [column[,column]...]...
37 ovsdb-client [options] wait [server] database state
38
39 Testing Commands:
40 ovsdb-client [options] lock [server] lock
41 ovsdb-client [options] steal [server] lock
42 ovsdb-client [options] unlock [server] lock
43
44 Other Commands:
45 ovsdb-client help
46
47 Cluster Options:
48 [--no-leader-only]
49
50 Output formatting options:
51 [--format=format] [--data=format] [--no-headings] [--pretty]
52 [--bare] [--timestamp]
53
54 Daemon options:
55 [--pidfile[=pidfile]] [--overwrite-pidfile] [--detach]
56 [--no-chdir] [--no-self-confinement]
57
58 Logging options:
59 [-v[module[:destination[:level]]]]...
60 [--verbose[=module[:destination[:level]]]]...
61 [--log-file[=file]]
62
63 Public key infrastructure options:
64 [--private-key=privkey.pem]
65 [--certificate=cert.pem]
66 [--ca-cert=cacert.pem]
67 [--bootstrap-ca-cert=cacert.pem]
68
69 SSL connection options:
70 [--ssl-protocols=protocols]
71 [--ssl-ciphers=ciphers]
72
73 Common options:
74 [-h | --help] [-V | --version]
75
76
78 The ovsdb-client program is a command-line client for interacting with
79 a running ovsdb-server process. Each command connects to the specified
80 OVSDB server, which may be an OVSDB active or passive connection
81 method, as described in ovsdb(7). The default server is
82 unix:/var/run/openvswitch/db.sock and the default database is
83 Open_vSwitch.
84
85 ovsdb-client supports the method1,method2,...,methodN syntax described
86 in ovsdb(7) for connecting to a cluster. When this syntax is used,
87 ovsdb-client tries the cluster members in random order until it finds
88 the cluster leader. Specify the --no-leader-only option to instead
89 accept any server that is connected to the cluster.
90
91 For an introduction to OVSDB and its implementation in Open vSwitch,
92 see ovsdb(7).
93
94 The following sections describe the commands that ovsdb-client sup‐
95 ports.
96
97 Server-Level Commands
98 Most ovsdb-client commands work with an individual database, but these
99 commands apply to an entire database server.
100
101 list-dbs [server]
102 Connects to server, retrieves the list of known databases, and
103 prints them one per line. These database names are the ones
104 that other commands may use for database.
105
106 Database Schema Commands
107 These commands obtain the schema from a database and print it or part
108 of it.
109
110 get-schema [server] [database]
111 Connects to server, retrieves the schema for database, and
112 prints it in JSON format.
113
114 list-tables [server] [database]
115 Connects to server, retrieves the schema for database, and
116 prints a table listing the name of each table within the data‐
117 base.
118
119 list-columns [server] [database] table
120 Connects to server, retrieves the schema for database, and
121 prints a table listing the name and type of each column. If ta‐
122 ble is specified, only columns in that table are listed; other‐
123 wise, the tables include columns in all tables.
124
125 Database Version Management Commands
126 An OVSDB schema has a schema version number, and an OVSDB database
127 embeds a particular version of an OVSDB schema. These version numbers
128 take the form x.y.z, e.g. 1.2.3. The OVSDB implementation does not
129 enforce a particular version numbering scheme, but schemas managed
130 within the Open vSwitch project use the following approach. Whenever
131 the database schema is changed in a non-backward compatible way (e.g.
132 deleting a column or a table), x is incremented (and y and z are reset
133 to 0). When the database schema is changed in a backward compatible
134 way (e.g. adding a new column), y is incremented (and z is reset to 0).
135 When the database schema is changed cosmetically (e.g. reindenting its
136 syntax), z is incremented.
137
138 Some OVSDB databases and schemas, especially very old ones, do not have
139 a version number.
140
141 Schema version numbers and Open vSwitch version numbers are indepen‐
142 dent.
143
144 These commands work with different versions of OVSDB schemas and data‐
145 bases.
146
147 convert [server] schema
148 Reads an OVSDB schema in JSON format, as specified in the OVSDB
149 specification, from schema, then connects to server and requests
150 the server to convert the database whose name is specified in
151 schema to the schema also specified in schema.
152
153 The conversion is atomic, consistent, isolated, and durable.
154 Following the schema change, the server notifies clients that
155 use the set_db_change_aware RPC introduced in Open vSwitch 2.9
156 and cancels their outstanding transactions and monitors. The
157 server disconnects other clients, enabling them to notice the
158 change when they reconnect.
159
160 This command can do simple ``upgrades'' and ``downgrades'' on a
161 database's schema. The data in the database must be valid when
162 interpreted under schema, with only one exception: data for
163 tables and columns that do not exist in schema are ignored.
164 Columns that exist in schema but not in the database are set to
165 their default values. All of schema's constraints apply in
166 full.
167
168 Some uses of this command can cause unrecoverable data loss.
169 For example, converting a database from a schema that has a
170 given column or table to one that does not will delete all data
171 in that column or table. Back up critical databases before con‐
172 verting them.
173
174 This command works with clustered and standalone databases.
175 Standalone databases may also be converted (offline) with
176 ovsdb-tool's convert command.
177
178 needs-conversion [server] schema
179 Reads the schema from schema, then connects to server and
180 requests the schema from the database whose name is specified in
181 schema. If the two schemas are the same, prints no on stdout;
182 if they differ, prints yes.
183
184 get-schema-version [server] [database]
185 Connects to server, retrieves the schema for database, and
186 prints its version number on stdout. If database was created
187 before schema versioning was introduced, then it will not have a
188 version number and this command will print a blank line.
189
190 get-schema-cksum [server] [database]
191 Connects to server, retrieves the schema for database, and
192 prints its checksum on stdout. If database does not include a
193 checksum, prints a blank line.
194
195 Data Management Commands
196 These commands read or modify the data in a database.
197
198 transact [server] transaction
199 Connects to server, sends it the specified transaction, which
200 must be a JSON array appropriate for use as the params to a
201 JSON-RPC transact request, and prints the received reply on std‐
202 out.
203
204 query [server] transaction
205 This commands acts like a read-only version of transact. It
206 connects to server, sends it the specified transaction, which
207 must be a JSON array appropriate for use as the params to a
208 JSON-RPC transact request, and prints the received reply on std‐
209 out. To ensure that the transaction does not modify the data‐
210 base, this command appends an abort operation to the set of
211 operations included in transaction before sending it to the
212 database, and then removes the abort result from the reply (if
213 it is present).
214
215 dump [server] [database] [table [column...]]
216 Connects to server, retrieves all of the data in database, and
217 prints it on stdout as a series of tables. If table is speci‐
218 fied, only that table is retrieved. If at least one column is
219 specified, only those columns are retrieved.
220
221 backup [server] [database] > snapshot
222 Connects to server, retrieves a snapshot of the schema and data
223 in database, and prints it on stdout in the format used for
224 OVSDB standalone and active-backup databases. This is an appro‐
225 priate way to back up any remote database. The database snap‐
226 shot that it outputs is suitable to be served up directly by
227 ovsdb-server or used as the input to ovsdb-client restore.
228
229 Another way to back up a standalone or active-backup database is
230 to copy its database file, e.g. with cp. This is safe even if
231 the database is in use.
232
233 The output does not include ephemeral columns, which by design
234 do not survive across restarts of ovsdb-server.
235
236 [--force] restore [server] [database] < snapshot
237 Reads snapshot, which must be a OVSDB standalone or active-
238 backup database (possibly but not necessarily created by
239 ovsdb-client backup). Then, connects to server, verifies that
240 database and snapshot have the same schema, then deletes all of
241 the data in database and replaces it by snapshot. The replace‐
242 ment happens atomically, in a single transaction.
243
244 UUIDs for rows in the restored database will differ from those
245 in snapshot, because the OVSDB protocol does not allow clients
246 to specify row UUIDs. Another way to restore a standalone or
247 active-backup database, which does also restore row UUIDs, is to
248 stop the server or servers, replace the database file by the
249 snapshot, then restart the database. Either way, ephemeral col‐
250 umns are not restored, since by design they do not survive
251 across restarts of ovsdb-server.
252
253 Normally restore exits with a failure if snapshot and the
254 server's database have different schemas. In such a case, it is
255 a good idea to convert the database to the new schema before
256 restoring, e.g. with ovsdb-client convert. Use --force to pro‐
257 ceed regardless of schema differences even though the restore
258 might fail with an error or succeed with surprising results.
259
260 monitor [server] [database] table [column[,column]...]...
261 monitor-cond [server] [database] conditions table [column[,col‐
262 umn]...]...
263 monitor-cond-since [server] [database] [last-id] conditions table [col‐
264 umn[,column]...]...
265 Connects to server and monitors the contents of rows that match
266 conditions in table in database. By default, the initial con‐
267 tents of table are printed, followed by each change as it
268 occurs. If conditions empty, all rows will be monitored. If at
269 least one column is specified, only those columns are monitored.
270 The following column names have special meanings:
271
272 !initial
273 Do not print the initial contents of the specified col‐
274 umns.
275
276 !insert
277 Do not print newly inserted rows.
278
279 !delete
280 Do not print deleted rows.
281
282 !modify
283 Do not print modifications to existing rows.
284
285 Multiple [column[,column]...] groups may be specified as sepa‐
286 rate arguments, e.g. to apply different reporting parameters to
287 each group. Whether multiple groups or only a single group is
288 specified, any given column may only be mentioned once on the
289 command line.
290
291 conditions is a JSON array of <condition> as defined in RFC 7047
292 5.1 with the following change: A condition can be either a
293 3-element JSON array as described in the RFC or a boolean value.
294
295 If --detach is used with monitor, monitor-cond or moni‐
296 tor-cond-since, then ovsdb-client detaches after it has success‐
297 fully received and printed the initial contents of table.
298
299 The monitor command uses RFC 7047 "monitor" method to open a
300 monitor session with the server. The monitor-cond and moni‐
301 tor-cond-since commandls uses RFC 7047 extension "monitor_cond"
302 and "monitor_cond_since" methods. See ovsdb-server(1) for
303 details.
304
305 monitor [server] [database] ALL
306 Connects to server and monitors the contents of all tables in
307 database. Prints initial values and all kinds of changes to all
308 columns in the database. The --detach option causes
309 ovsdb-client to detach after it successfully receives and prints
310 the initial database contents.
311
312 The monitor command uses RFC 7047 "monitor" method to open a
313 monitor session with the server.
314
315 wait [server] database state
316 Waits for database on server to enter a desired state, which may
317 be one of:
318
319 added Waits until a database with the given name has been added
320 to server.
321
322 connected
323 Waits until a database with the given name has been added
324 to server. Then, if database is clustered, additionally
325 waits until it has joined and connected to its cluster.
326
327 removed
328 Waits until database has been removed from the database
329 server. This can also be used to wait for a database to
330 complete leaving its cluster, because ovsdb-server
331 removes a database at that point.
332
333 database is mandatory for this command because it is often used
334 to check for databases that have not yet been added to the
335 server, so that the ovsdb-client semantics of acting on a
336 default database do not work.
337
338 This command acts on a particular database server, not on a
339 cluster, so server must name a single server, not a comma-delim‐
340 ited list of servers.
341
342 Testing commands
343 These commands are mostly of interest for testing the correctness of
344 the OVSDB server.
345
346 lock [server] lock
347 steal [server] lock
348 unlock [server] lock
349 Connects to server and issues corresponding RFC 7047 lock opera‐
350 tions on lock. Prints json reply or subsequent update messages.
351 The --detach option causes ovsdb-client to detach after it suc‐
352 cessfully receives and prints the initial reply.
353
354 When running with the --detach option, lock, steal, unlock and
355 exit commands can be issued by using ovs-appctl. exit command
356 causes the ovsdb-client to close its ovsdb-server connection
357 before exit. The lock, steal and unlock commands can be used to
358 issue additional lock operations over the same ovsdb-server con‐
359 nection. All above commands take a single lock argument, which
360 does not have to be the same as the lock that ovsdb-client
361 started with.
362
364 Output Formatting Options
365 Much of the output from ovsdb-client is in the form of tables. The
366 following options controlling output formatting:
367
368 -f format
369 --format=format
370 Sets the type of table formatting. The following types of for‐
371 mat are available:
372
373 table (default)
374 2-D text tables with aligned columns.
375
376 list A list with one column per line and rows separated by a
377 blank line.
378
379 html HTML tables.
380
381 csv Comma-separated values as defined in RFC 4180.
382
383 json JSON format as defined in RFC 4627. The output is a
384 sequence of JSON objects, each of which corresponds to
385 one table. Each JSON object has the following members
386 with the noted values:
387
388 caption
389 The table's caption. This member is omitted if
390 the table has no caption.
391
392 headings
393 An array with one element per table column. Each
394 array element is a string giving the corresponding
395 column's heading.
396
397 data An array with one element per table row. Each
398 element is also an array with one element per ta‐
399 ble column. The elements of this second-level
400 array are the cells that constitute the table.
401 Cells that represent OVSDB data or data types are
402 expressed in the format described in the OVSDB
403 specification; other cells are simply expressed as
404 text strings.
405
406 -d format
407 --data=format
408 Sets the formatting for cells within output tables unless the
409 table format is set to json, in which case json formatting is
410 always used when formatting cells. The following types of for‐
411 mat are available:
412
413 string (default)
414 The simple format described in the Database Values sec‐
415 tion of ovs-vsctl(8).
416
417 bare The simple format with punctuation stripped off: [] and
418 {} are omitted around sets, maps, and empty columns,
419 items within sets and maps are space-separated, and
420 strings are never quoted. This format may be easier for
421 scripts to parse.
422
423 json The RFC 4627 JSON format as described above.
424
425 --no-headings
426 This option suppresses the heading row that otherwise appears in
427 the first row of table output.
428
429 --pretty
430 By default, JSON in output is printed as compactly as possible.
431 This option causes JSON in output to be printed in a more read‐
432 able fashion. Members of objects and elements of arrays are
433 printed one per line, with indentation.
434
435 This option does not affect JSON in tables, which is always
436 printed compactly.
437
438 --bare Equivalent to --format=list --data=bare --no-headings.
439
440 --max-column-width=n
441 For table output only, limits the width of any column in the
442 output to n columns. Longer cell data is truncated to fit, as
443 necessary. Columns are always wide enough to display the column
444 names, if the heading row is printed.
445
446 --timestamp
447 For the monitor, monitor-cond and monitor-cond-since commands,
448 add a timestamp to each table update. Most output formats add
449 the timestamp on a line of its own just above the table. The
450 JSON output format puts the timestamp in a member of the top-
451 level JSON object named time.
452
453 -t
454 --timeout=secs
455 Limits ovsdb-client runtime to approximately secs seconds. If
456 the timeout expires, ovsdb-client will exit with a SIGALRM sig‐
457 nal.
458
459 Daemon Options
460 The daemon options apply only to the monitor, monitor-cond and moni‐
461 tor-cond-since commands. With any other command, they have no effect.
462
463 The following options are valid on POSIX based platforms.
464
465 --pidfile[=pidfile]
466 Causes a file (by default, ovsdb-client.pid) to be created indi‐
467 cating the PID of the running process. If the pidfile argument
468 is not specified, or if it does not begin with /, then it is
469 created in /var/run/openvswitch.
470
471 If --pidfile is not specified, no pidfile is created.
472
473 --overwrite-pidfile
474 By default, when --pidfile is specified and the specified pid‐
475 file already exists and is locked by a running process,
476 ovsdb-client refuses to start. Specify --overwrite-pidfile to
477 cause it to instead overwrite the pidfile.
478
479 When --pidfile is not specified, this option has no effect.
480
481 --detach
482 Runs ovsdb-client as a background process. The process forks,
483 and in the child it starts a new session, closes the standard
484 file descriptors (which has the side effect of disabling logging
485 to the console), and changes its current directory to the root
486 (unless --no-chdir is specified). After the child completes its
487 initialization, the parent exits.
488
489 --monitor
490 Creates an additional process to monitor the ovsdb-client dae‐
491 mon. If the daemon dies due to a signal that indicates a pro‐
492 gramming error (SIGABRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIG‐
493 PIPE, SIGSEGV, SIGXCPU, or SIGXFSZ) then the monitor process
494 starts a new copy of it. If the daemon dies or exits for
495 another reason, the monitor process exits.
496
497 This option is normally used with --detach, but it also func‐
498 tions without it.
499
500 --no-chdir
501 By default, when --detach is specified, ovsdb-client changes its
502 current working directory to the root directory after it
503 detaches. Otherwise, invoking ovsdb-client from a carelessly
504 chosen directory would prevent the administrator from unmounting
505 the file system that holds that directory.
506
507 Specifying --no-chdir suppresses this behavior, preventing
508 ovsdb-client from changing its current working directory. This
509 may be useful for collecting core files, since it is common
510 behavior to write core dumps into the current working directory
511 and the root directory is not a good directory to use.
512
513 This option has no effect when --detach is not specified.
514
515 --no-self-confinement
516 By default daemon will try to self-confine itself to work with
517 files under well-known directories determined during build. It
518 is better to stick with this default behavior and not to use
519 this flag unless some other Access Control is used to confine
520 daemon. Note that in contrast to other access control implemen‐
521 tations that are typically enforced from kernel-space (e.g. DAC
522 or MAC), self-confinement is imposed from the user-space daemon
523 itself and hence should not be considered as a full confinement
524 strategy, but instead should be viewed as an additional layer of
525 security.
526
527 --user Causes ovsdb-client to run as a different user specified in
528 "user:group", thus dropping most of the root privileges. Short
529 forms "user" and ":group" are also allowed, with current user or
530 group are assumed respectively. Only daemons started by the root
531 user accepts this argument.
532
533 On Linux, daemons will be granted CAP_IPC_LOCK and
534 CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
535 that interact with a datapath, such as ovs-vswitchd, will be
536 granted three additional capabilities, namely CAP_NET_ADMIN,
537 CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
538 apply even if the new user is root.
539
540 On Windows, this option is not currently supported. For security
541 reasons, specifying this option will cause the daemon process
542 not to start.
543
544 Logging Options
545 -v[spec]
546 --verbose=[spec]
547 Sets logging levels. Without any spec, sets the log level for
548 every module and destination to dbg. Otherwise, spec is a list
549 of words separated by spaces or commas or colons, up to one from
550 each category below:
551
552 · A valid module name, as displayed by the vlog/list com‐
553 mand on ovs-appctl(8), limits the log level change to the
554 specified module.
555
556 · syslog, console, or file, to limit the log level change
557 to only to the system log, to the console, or to a file,
558 respectively. (If --detach is specified, ovsdb-client
559 closes its standard file descriptors, so logging to the
560 console will have no effect.)
561
562 On Windows platform, syslog is accepted as a word and is
563 only useful along with the --syslog-target option (the
564 word has no effect otherwise).
565
566 · off, emer, err, warn, info, or dbg, to control the log
567 level. Messages of the given severity or higher will be
568 logged, and messages of lower severity will be filtered
569 out. off filters out all messages. See ovs-appctl(8)
570 for a definition of each log level.
571
572 Case is not significant within spec.
573
574 Regardless of the log levels set for file, logging to a file
575 will not take place unless --log-file is also specified (see
576 below).
577
578 For compatibility with older versions of OVS, any is accepted as
579 a word but has no effect.
580
581 -v
582 --verbose
583 Sets the maximum logging verbosity level, equivalent to --ver‐
584 bose=dbg.
585
586 -vPATTERN:destination:pattern
587 --verbose=PATTERN:destination:pattern
588 Sets the log pattern for destination to pattern. Refer to
589 ovs-appctl(8) for a description of the valid syntax for pattern.
590
591 -vFACILITY:facility
592 --verbose=FACILITY:facility
593 Sets the RFC5424 facility of the log message. facility can be
594 one of kern, user, mail, daemon, auth, syslog, lpr, news, uucp,
595 clock, ftp, ntp, audit, alert, clock2, local0, local1, local2,
596 local3, local4, local5, local6 or local7. If this option is not
597 specified, daemon is used as the default for the local system
598 syslog and local0 is used while sending a message to the target
599 provided via the --syslog-target option.
600
601 --log-file[=file]
602 Enables logging to a file. If file is specified, then it is
603 used as the exact name for the log file. The default log file
604 name used if file is omitted is /var/log/open‐
605 vswitch/ovsdb-client.log.
606
607 --syslog-target=host:port
608 Send syslog messages to UDP port on host, in addition to the
609 system syslog. The host must be a numerical IP address, not a
610 hostname.
611
612 --syslog-method=method
613 Specify method how syslog messages should be sent to syslog dae‐
614 mon. Following forms are supported:
615
616 · libc, use libc syslog() function. Downside of using this
617 options is that libc adds fixed prefix to every message
618 before it is actually sent to the syslog daemon over
619 /dev/log UNIX domain socket.
620
621 · unix:file, use UNIX domain socket directly. It is possi‐
622 ble to specify arbitrary message format with this option.
623 However, rsyslogd 8.9 and older versions use hard coded
624 parser function anyway that limits UNIX domain socket
625 use. If you want to use arbitrary message format with
626 older rsyslogd versions, then use UDP socket to localhost
627 IP address instead.
628
629 · udp:ip:port, use UDP socket. With this method it is pos‐
630 sible to use arbitrary message format also with older
631 rsyslogd. When sending syslog messages over UDP socket
632 extra precaution needs to be taken into account, for
633 example, syslog daemon needs to be configured to listen
634 on the specified UDP port, accidental iptables rules
635 could be interfering with local syslog traffic and there
636 are some security considerations that apply to UDP sock‐
637 ets, but do not apply to UNIX domain sockets.
638
639 · null, discards all messages logged to syslog.
640
641 The default is taken from the OVS_SYSLOG_METHOD environment
642 variable; if it is unset, the default is libc.
643
644 Public Key Infrastructure Options
645 -p privkey.pem
646 --private-key=privkey.pem
647 Specifies a PEM file containing the private key used as
648 ovsdb-client's identity for outgoing SSL connections.
649
650 -c cert.pem
651 --certificate=cert.pem
652 Specifies a PEM file containing a certificate that certifies the
653 private key specified on -p or --private-key to be trustworthy.
654 The certificate must be signed by the certificate authority (CA)
655 that the peer in SSL connections will use to verify it.
656
657 -C cacert.pem
658 --ca-cert=cacert.pem
659 Specifies a PEM file containing the CA certificate that
660 ovsdb-client should use to verify certificates presented to it
661 by SSL peers. (This may be the same certificate that SSL peers
662 use to verify the certificate specified on -c or --certificate,
663 or it may be a different one, depending on the PKI design in
664 use.)
665
666 -C none
667 --ca-cert=none
668 Disables verification of certificates presented by SSL peers.
669 This introduces a security risk, because it means that certifi‐
670 cates cannot be verified to be those of known trusted hosts.
671
672 --bootstrap-ca-cert=cacert.pem
673 When cacert.pem exists, this option has the same effect as -C or
674 --ca-cert. If it does not exist, then ovsdb-client will attempt
675 to obtain the CA certificate from the SSL peer on its first SSL
676 connection and save it to the named PEM file. If it is success‐
677 ful, it will immediately drop the connection and reconnect, and
678 from then on all SSL connections must be authenticated by a cer‐
679 tificate signed by the CA certificate thus obtained.
680
681 This option exposes the SSL connection to a man-in-the-middle
682 attack obtaining the initial CA certificate, but it may be use‐
683 ful for bootstrapping.
684
685 This option is only useful if the SSL peer sends its CA certifi‐
686 cate as part of the SSL certificate chain. The SSL protocol
687 does not require the server to send the CA certificate.
688
689 This option is mutually exclusive with -C and --ca-cert.
690
691 SSL Connection Options
692 --ssl-protocols=protocols
693 Specifies, in a comma- or space-delimited list, the SSL proto‐
694 cols ovsdb-client will enable for SSL connections. Supported
695 protocols include TLSv1, TLSv1.1, and TLSv1.2. Regardless of
696 order, the highest protocol supported by both sides will be cho‐
697 sen when making the connection. The default when this option is
698 omitted is TLSv1,TLSv1.1,TLSv1.2.
699
700 --ssl-ciphers=ciphers
701 Specifies, in OpenSSL cipher string format, the ciphers
702 ovsdb-client will support for SSL connections. The default when
703 this option is omitted is HIGH:!aNULL:!MD5.
704
705 Other Options
706 -h
707 --help Prints a brief help message to the console.
708
709 -V
710 --version
711 Prints version information to the console.
712
714 ovsdb(7), ovsdb-server(1), ovsdb-client(1).
715
716
717
718Open vSwitch 2.15.0 ovsdb-client(1)