ovsdb-client(1)

📦
version 4.0.0 · 13 versions
, in arch rolling

💅 ovsdb-client(1) — Open vSwitch Manual 💅

okay so this is the man page for ovsdb-client, bestie, and it's literally your all-access pass to a running ovsdb-server. buckle up 🎀

✨ NAME ✨

ovsdb-client — command-line interface to ovsdb-server(1) 🦋

🌈 SYNOPSIS 🌈

okay so the synopsis is lowkey a whole vibe — it's grouped by what each command actually does, so let's keep that energy 💖

Server-Level Commands:

ovsdb-client [options] list-dbs [server]

Database Schema Commands:

ovsdb-client [options] get-schema [server] [database]
ovsdb-client [options] list-tables [server] [database]
ovsdb-client [options] list-columns [server] [database] [table]

Database Version Management Commands:

ovsdb-client [options] convert [server] schema
ovsdb-client [options] needs-conversion [server] schema
ovsdb-client [options] get-schema-version [server] [database]

Data Management Commands:

ovsdb-client [options] transact [server] transaction
ovsdb-client [options] query [server] transaction
ovsdb-client [options] dump [server] [database] [table [column...]]
ovsdb-client [options] backup [server] [database] > snapshot
ovsdb-client [options] [--force] restore [server] [database] < snapshot
ovsdb-client [options] monitor [server] [database] table [column[,column]...]...
ovsdb-client [options] monitor [server] [database] ALL
ovsdb-client [options] monitor-cond [server] [database] conditions table [column[,column]...]...
ovsdb-client [options] monitor-cond-since [server] [database] [last-id] conditions table [column[,column]...]...
ovsdb-client [options] wait [server] database state

Testing Commands:

ovsdb-client [options] lock [server] lock
ovsdb-client [options] steal [server] lock
ovsdb-client [options] unlock [server] lock

Other Commands:

ovsdb-client help

Cluster Options:

[--no-leader-only]

Output formatting options:

[--format=format] [--data=format] [--no-headings] [--pretty] [--bare] [--timestamp]

Daemon options:

[--pidfile[=pidfile]] [--overwrite-pidfile] [--detach] [--no-chdir] [--no-self-confinement]

Logging options:

[-v[module[:destination[:level]]]]...
[--verbose[=module[:destination[:level]]]]...
[--log-file[=file]]

Public key infrastructure options:

[--private-key=privkey.pem]
[--certificate=cert.pem]
[--ca-cert=cacert.pem]
[--ssl-server-name=servername]
[--bootstrap-ca-cert=cacert.pem]

SSL/TLS connection options:

[--ssl-protocols=protocols]
[--ssl-ciphers=ciphers]
[--ssl-ciphersuites=ciphersuites]

Replay options:

[--record[=directory]] [--replay[=directory]]

Common options:

[-h | --help] [-V | --version]

💖 DESCRIPTION 💖

so ovsdb-client is literally the command-line client for talking to a running ovsdb-server process, no cap 🫶 Every single command connects to the OVSDB server you point it at, and that server can be an OVSDB active or passive connection method — all the deets live in ovsdb(7). icon behavior ✨

the defaults, so you don't gotta type them:

  • default server → unix:/run/openvetw...

wait, scratch that 💀 — default server is unix:/run/openvswitch/db.sock

  • default database → Open_vSwitch

ovsdb-client also supports the method1,method2,...,methodN syntax that ovsdb(7) describes for connecting to a cluster. When you use that syntax, it tries the cluster members in random order until it finds the cluster leader — main character energy, honestly 👑. If you'd rather just accept any server that's connected to the cluster, pass --no-leader-only.

for the full intro to OVSDB and how Open vSwitch implements it, go read ovsdb(7) — it's giving required reading 📚

and now, the commands. the following sections describe everything ovsdb-client can do 💅

🫶 Server-Level Commands

most ovsdb-client commands work on one individual database, but these ones apply to a whole entire database server — big-picture energy 🌸

list-dbs [server]

connects to server, grabs the list of known databases, and prints them one per line ✨ these database names are exactly the ones other commands can use for database. iykyk.

🦋 Database Schema Commands

these commands pull the schema out of a database and print it, or print part of it. very demure, very mindful 🎀

get-schema [server] [database]

connects to server, retrieves the schema for database, and prints it in JSON format 💖

list-tables [server] [database]

connects to server, retrieves the schema for database, and prints a table listing the name of each table within the database. iconic little table of tables 🍓

list-columns [server] [database] table

connects to server, retrieves the schema for database, and prints a table listing the name and type of each column. if table is specified, only columns in that table get listed; otherwise, the tables include columns in all tables. all of them. every last one 👑

🌟 Database Version Management Commands

okay so an OVSDB schema has a schema version number, and an OVSDB database embeds a particular version of an OVSDB schema. these version numbers look like x.y.z, e.g. 1.2.3 🔢

the OVSDB implementation does not enforce a particular version numbering scheme, but schemas managed within the Open vSwitch project use this approach:

  • whenever the database schema changes in a non-backward compatible way (e.g. deleting a column or a table), x is incremented — and y and z are reset to 0
  • when the database schema changes in a backward compatible way (e.g. adding a new column), y is incremented — and z is reset to 0
  • when the database schema changes cosmetically (e.g. reindenting its syntax), z is incremented

some OVSDB databases and schemas, especially very old ones, do not have a version number at all 🙈

also important: schema version numbers and Open vSwitch version numbers are independent — they're not the same thing, don't mix them up bestie 💀

these commands work with different versions of OVSDB schemas and databases 🫶

convert [server] schema

reads an OVSDB schema in JSON format, as specified in the OVSDB specification, from schema, then connects to server and requests that the server convert the database whose name is specified in schema to the schema also specified in schema. it's giving glow-up 💅

the conversion is atomic, consistent, isolated, and durable ✨ following the schema change, the server notifies clients that use the set_db_change_aware RPC introduced in Open vSwitch 2.9 and cancels their outstanding transactions and monitors. the server disconnects other clients, enabling them to notice the change when they reconnect. messy but necessary 😭

this command can do simple upgrades'' and downgrades'' on a database's schema. the data in the database must be valid when interpreted under schema, with exactly one exception: data for tables and columns that do not exist in schema are ignored. columns that exist in schema but not in the database are set to their default values. all of schema's constraints apply in full. periodt.

⚠️ bestie please read this one ⚠️ some uses of this command can cause unrecoverable data loss. for example, converting a database from a schema that has a given column or table to one that does not will delete all data in that column or table. back up critical databases before converting them. not me being dramatic, this is literally in the manual 💀

this command works with clustered and standalone databases. standalone databases may also be converted (offline) with ovsdb-tool's convert command 🧚

needs-conversion [server] schema

reads the schema from schema, then connects to server and requests the schema from the database whose name is specified in schema. if the two schemas are the same, it prints no on stdout; if they differ, it prints yes. that's it. that's the whole vibe check ✅

get-schema-version [server] [database]

connects to server, retrieves the schema for database, and prints its version number on stdout 🎀

if database was created before schema versioning was introduced, then it will not have a version number and this command will print a blank line. awkward but valid 🙈

get-schema-cksum [server] [database]

connects to server, retrieves the schema for database, and prints its checksum on stdout ✨

if database does not include a checksum, it prints a blank line. same energy as above 🫶

💜 Data Management Commands

these commands read or modify the data in a database. the fun ones 🔥

transact [server] transaction

connects to server, sends it the specified transaction, which must be a JSON array appropriate for use as the params to a JSON-RPC transact request, and prints the received reply on stdout 🦋

query [server] transaction

this command acts like a read-only version of transact. it connects to server, sends it the specified transaction, which must be a JSON array appropriate for use as the params to a JSON-RPC transact request, and prints the received reply on stdout.

and here's the clever bit 👑 — to make sure the transaction does not modify the database, this command appends an abort operation to the set of operations included in transaction before sending it to the database, and then removes the abort result from the reply (if it is present). not me gaslighting the server into thinking it can't write 😭

dump [server] [database] [table [column...]]

connects to server, retrieves all of the data in database, and prints it on stdout as a series of tables. if table is specified, only that table is retrieved. if at least one column is specified, only those columns are retrieved. cherry-picking, but make it data 🍓

backup [server] [database] > snapshot

connects to server, retrieves a snapshot of the schema and data in database, and prints it on stdout in the format used for OVSDB standalone and active-backup databases 💾

this is an appropriate way to back up any remote database. the database snapshot that it outputs is suitable to be served up directly by ovsdb-server or used as the input to ovsdb-client restore. slay, honestly ✨

another way to back up a standalone or active-backup database is to just copy its database file, e.g. with cp. this is safe even if the database is in use 🫶

🎀 heads up: the output does not include ephemeral columns, which by design do not survive across restarts of ovsdb-server. they're ephemeral for a reason bestie.

[--force] restore [server] [database] < snapshot

reads snapshot, which must be an OVSDB standalone or active-backup database (possibly but not necessarily created by ovsdb-client backup). then it connects to server, verifies that database and snapshot have the same schema, then deletes all of the data in database and replaces it by snapshot. 💀

the replacement happens atomically, in a single transaction — no half-restored mess, we love to see it 👑

...the UUIDs for the rows in your restored database are gonna be different from the ones in the snapshot, and that's just how it is 😭 because the OVSDB protocol straight-up does not let clients specify row UUIDs. It's giving "rules are rules."

So there's another way to restore a standalone or active-backup database — and this route does bring the row UUIDs back too: stop the server (or servers), replace the database file with the snapshot, then restart the database. Old-school but it works 💅

Either way, ephemeral columns do not get restored, because by design they do not survive across restarts of ovsdb-server. Not a bug, bestie, that's the whole point of them.

Normally restore exits with a failure if the snapshot and the server's database have different schemas. If that happens to you, the move is to convert the database to the new schema before restoring — e.g. with ovsdb-client convert. ✨ And if you really wanna just send it, --force makes it proceed regardless of schema differences, even though the restore might fail with an error or succeed with surprising results 🙈 (you've been warned, that's the whole warning).

monitor [server] [database] table [column[,column]...]...
monitor-cond [server] [database] conditions table [column[,column]...]...
monitor-cond-since [server] [database] [last-id] conditions table [column[,column]...]...

Connects to server and monitors the contents of rows that match conditions in table in database. By default, the initial contents of table get printed, and then every change as it happens — like a livestream, but for rows 🦋

If conditions is empty, all rows will be monitored. If you specify at least one column, only those columns are monitored. And these column names are ✨special✨:

  • !initial — do not print the initial contents of the specified columns.
  • !insert — do not print newly inserted rows.
  • !delete — do not print deleted rows.
  • !modify — do not print modifications to existing rows.

You can pass multiple [column[,column]...] groups as separate arguments — say, to apply different reporting parameters to each group. But whether you pass multiple groups or only a single group, any given column may only be mentioned once on the command line. One mention per column, periodt.

conditions is a JSON array of <condition> as defined in RFC 7047 5.1, with this one change: a condition can be either a 3-element JSON array as described in the RFC or a boolean value. Yep, both. Slay.

If --detach is used with monitor, monitor-cond or monitor-cond-since, then ovsdb-client detaches once it has successfully received and printed the initial contents of table.

The monitor command uses the RFC 7047 "monitor" method to open a monitor session with the server. The monitor-cond and monitor-cond-since commands use the RFC 7047 extensions "monitor_cond" and "monitor_cond_since" methods. See ovsdb-server(1) for the details, iykyk.

monitor [server] [database] ALL

Connects to server and monitors the contents of all tables in database. Prints initial values and all kinds of changes to all columns in the database — the whole thing, no filter, main character energy 👑 The --detach option causes ovsdb-client to detach after it successfully receives and prints the initial database contents.

The monitor command uses the RFC 7047 "monitor" method to open a monitor session with the server.

wait [server] database state

Waits for database on server to enter a desired state, which may be one of:

  • added — waits until a database with the given name has been added to server.
  • connected — waits until a database with the given name has been added to server. Then, if database is clustered, additionally waits until it has joined and connected to its cluster.
  • removed — waits until database has been removed from the database server. This can also be used to wait for a database to complete leaving its cluster, because ovsdb-server removes a database at that point.

database is mandatory for this command because it's often used to check for databases that have not yet been added to the server — so the usual ovsdb-client semantics of acting on a default database just don't work here 🙅‍♀️

Also: this command acts on a particular database server, not on a cluster, so server must name a single server — NOT a comma-delimited list of servers.

🧪 Testing commands 🧪

These commands are mostly of interest for testing the correctness of the OVSDB server. Quality assurance girlies, this one's for you.

lock [server] lock
steal [server] lock
unlock [server] lock

Connects to server and issues the corresponding RFC 7047 lock operations on lock. Prints the json reply or subsequent update messages. The --detach option causes ovsdb-client to detach after it successfully receives and prints the initial reply.

When running with the --detach option, lock, steal, unlock and exit commands can be issued by using ovs-appctl. The exit command causes ovsdb-client to close its ovsdb-server connection before exit. The lock, steal and unlock commands can be used to issue additional lock operations over the same ovsdb-server connection. All of the above commands take a single lock argument, which does not have to be the same as the lock that ovsdb-client started with. Mix and match, honestly 💅

✨ OPTIONS ✨

🎀 Output Formatting Options 🎀

Much of the output from ovsdb-client is in the form of tables. The following options control output formatting:

  • -f format, --format=format — sets the type of table formatting. The following types of format are available:
    • table (default) — 2-D text tables with aligned columns.
    • list — a list with one column per line and rows separated by a blank line.
    • html — HTML tables.
    • csv — comma-separated values as defined in RFC 4180.
    • json — JSON format as defined in RFC 4627. The output is a sequence of JSON objects, each of which corresponds to one table. Each JSON object has the following members with the noted values:
      • caption — the table's caption. This member is omitted if the table has no caption.
      • headings — an array with one element per table column. Each array element is a string giving the corresponding column's heading.
      • data — an array with one element per table row. Each element is also an array with one element per table column. The elements of this second-level array are the cells that constitute the table. Cells that represent OVSDB data or data types are expressed in the format described in the OVSDB specification; other cells are simply expressed as text strings.
  • -d format, --data=format — sets the formatting for cells within output tables unless the table format is set to json, in which case json formatting is always used when formatting cells. The following types of format are available:
    • string (default) — the simple format described in the Database Values section of ovs-vsctl(8).
    • bare — the simple format with punctuation stripped off: [] and {} are omitted around sets, maps, and empty columns, items within sets and maps are space-separated, and strings are never quoted. This format may be easier for scripts to parse. Script girlies, this is your moment 🌸
    • json — the RFC 4627 JSON format as described above.
  • --no-headings — this option suppresses the heading row that otherwise appears in the first row of table output.
  • --pretty — by default, JSON in output is printed as compactly as possible. This option causes JSON in output to be printed in a more readable fashion. Members of objects and elements of arrays are printed one per line, with indentation.
Heads up 🫶 this option does not affect JSON in tables, which is always printed compactly. Tables stay compact, no cap.
  • --bare — equivalent to --format=list --data=bare --no-headings. One flag, three vibes.
  • --max-column-width=n — for table output only, limits the width of any column in the output to n columns. Longer cell data is truncated to fit, as necessary. Columns are always wide enough to display the column names, if the heading row is printed. (So your headers never get clapped, basically.)
  • --timestamp — for the monitor, monitor-cond and monitor-cond-since commands, adds a timestamp to each table update. Most output formats add the timestamp on a line of its own just above the table. The JSON output format puts the timestamp in a member of the top-level JSON object named time.
  • -t secs, --timeout=secs — limits ovsdb-client runtime to approximately secs seconds. If the timeout expires, ovsdb-client will exit with a SIGALRM signal. ⏰ Rude but effective.

👑 Daemon Options 👑

The daemon options apply only to the monitor, monitor-cond and monitor-cond-since commands. With any other command, they have no effect. (Zero, none, nada.)

The following options are valid on POSIX based platforms.

  • --pidfile[=pidfile] — causes a file (by default, ovsdb-client.pid) to be created indicating the PID of the running process. If the pidfile argument is not specified, or if it does not begin with /, then it is created in /run/openvswitch.

If --pidfile is not specified, no pidfile is created.

  • --overwrite-pidfile — by default, when --pidfile is specified and the specified pidfile already exists and is locked by a running process, ovsdb-client refuses to start. Specify --overwrite-pidfile to cause it to instead overwrite the pidfile.
When --pidfile is not specified, this option has no effect. 💀
  • --detach — runs ovsdb-client as a background process. The process forks, and in the child it starts a new session, closes the standard file descriptors (which has the side effect of disabling logging to the console), and changes its current directory to the root (unless --no-chdir is specified). After the child completes its initialization, the parent exits.
  • --monitor — bestie, this creates an additional process to monitor the ovsdb-client daemon. If the daemon dies due to a signal that indicates a programming error (SIGABRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU, or SIGXFSZ) then the monitor process starts a new copy of it. If the daemon dies or exits for another reason, the monitor process exits.

This option is normally used with --detach, but it also functions without it. 💅

  • --no-chdir — by default, when --detach is specified, ovsdb-client changes its current working directory to the root directory after it detaches. Otherwise, invoking ovsdb-client from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory.

Specifying --no-chdir suppresses this behavior, preventing ovsdb-client from changing its current working directory. This may be useful for collecting core files, since it is common behavior to write core dumps into the current working directory and the root directory is not a good directory to use.

This option has no effect when --detach is not specified.

  • --no-self-confinement — by default daemon will try to self-confine itself to work with files under well-known directories determined during build. It is better to stick with this default behavior and not to use this flag unless some other Access Control is used to confine daemon. Note that in contrast to other access control implementations that are typically enforced from kernel-space (e.g. DAC or MAC), self-confinement is imposed from the user-space daemon itself and hence should not be considered as a full confinement strategy, but instead should be viewed as an additional layer of security.
  • --user — causes ovsdb-client to run as a different user specified in "user:group", thus dropping most of the root privileges. Short forms "user" and ":group" are also allowed, with current user or group are assumed respectively. Only daemons started by the root user accepts this argument.

On Linux, daemons will be granted CAP_IPC_LOCK and CAP_NET_BIND_SERVICES before dropping root privileges. Daemons that interact with a datapath, such as ovs-vswitchd, will be granted three additional capabilities, namely CAP_NET_ADMIN, CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will apply even if the new user is root. 👑

🪵 Logging Options 🪵

  • -v[spec], --verbose=[spec] — sets logging levels. Without any spec, sets the log level for every module and destination to dbg. Otherwise, spec is a list of words separated by spaces or commas or colons, up to one from each category below:
    • A valid module name, as displayed by the vlog/list command on ovs-appctl(8), limits the log level change to the specified module.
    • syslog, console, or file, to limit the log level change to only to the system log, to the console, or to a file, respectively. (If --detach is specified, ovsdb-client closes its standard file descriptors, so logging to the console will have no effect.)
    • off, emer, err, warn, info, or dbg, to control the log level. Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out. off filters out all messages. See ovs-appctl(8) for a definition of each log level.

Case is not significant within spec.

Regardless of the log levels set for file, logging to a file will not take place unless --log-file is also specified (see below).

For compatibility with older versions of OVS, any is accepted as a word but has no effect.

  • -v, --verbose — sets the maximum logging verbosity level, equivalent to --verbose=dbg. ✨
  • -vPATTERN:destination:pattern, --verbose=PATTERN:destination:pattern — sets the log pattern for destination to pattern. Refer to ovs-appctl(8) for a description of the valid syntax for pattern.
  • -vFACILITY:facility, --verbose=FACILITY:facility — sets the RFC5424 facility of the log message. facility can be one of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock, ftp, ntp, audit, alert, clock2, local0, local1, local2, local3, local4, local5, local6 or local7. If this option is not specified, daemon is used as the default for the local system syslog and local0 is used while sending a message to the target provided via the --syslog-target option.
  • --log-file[=file] — enables logging to a file. If file is specified, then it is used as the exact name for the log file. The default log file name used if file is omitted is /var/log/openvswitch/ovsdb-client.log.
  • --syslog-target=host:port — send syslog messages to UDP port on host, in addition to the system syslog. The host must be a numerical IP address, not a hostname.
  • --syslog-method=method — specify method how syslog messages should be sent to syslog daemon. Following forms are supported:
    • libc, use libc syslog() function. Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over /dev/log UNIX domain socket.
    • unix:file, use UNIX domain socket directly. It is possible to specify arbitrary message format with this option. However, rsyslogd 8.9 and older versions use hard coded parser function anyway that limits UNIX domain socket use. If you want to use arbitrary message format with older rsyslogd versions, then use UDP socket to localhost IP address instead.
    • udp:ip:port, use UDP socket. With this method it is possible to use arbitrary message format also with older rsyslogd. When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, syslog daemon needs to be configured to listen on the specified UDP port, accidental iptables rules could be interfering with local syslog traffic and there are some security considerations that apply to UDP sockets, but do not apply to UNIX domain sockets.
    • null, discards all messages logged to syslog.

The default is taken from the OVS_SYSLOG_METHOD environment variable; if it is unset, the default is libc.

🔐 Public Key Infrastructure Options 🔐

  • -p privkey.pem, --private-key=privkey.pem — specifies a PEM file containing the private key used as ovsdb-client's identity for outgoing SSL/TLS connections.
  • -c cert.pem, --certificate=cert.pem — specifies a PEM file containing a certificate that certifies the private key specified on -p or --private-key to be trustworthy. The certificate must be signed by the certificate authority (CA) that the peer in SSL/TLS connections will use to verify it.
  • -C cacert.pem, --ca-cert=cacert.pem — specifies a PEM file containing the CA certificate that ovsdb-client should use to verify certificates presented to it by SSL/TLS peers. (This may be the same certificate that SSL/TLS peers use to verify the certificate specified on -c or --certificate, or it may be a different one, depending on the PKI design in use.)
  • -C none, --ca-cert=none — disables verification of certificates presented by SSL/TLS peers. This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts.
🚨 Security tea: this is a real risk, not a vibe. Cert verification is literally off.
  • --ssl-server-name=servername — specifies the server name to use for TLS Server Name Indication (SNI). By default, the hostname from the connection string is used for SNI. This option allows overriding the SNI hostname, which is useful when connecting through proxies or service meshes where the connection endpoint differs from the intended server name.
  • --bootstrap-ca-cert=cacert.pem — when cacert.pem exists, this option has the same effect as -C or --ca-cert. If it does not exist, then ovsdb-client will attempt to obtain the CA certificate from the SSL/TLS peer on its first SSL/TLS connection and save it to the named PEM file. If it is successful, it will immediately drop the connection and reconnect, and from then on all SSL/TLS connections must be authenticated by a certificate signed by the CA certificate thus obtained.

This option exposes the SSL/TLS connection to a man-in-the-middle attack obtaining the initial CA certificate, but it may be useful for bootstrapping.

This option is only useful if the SSL/TLS peer sends its CA certificate as part of the SSL/TLS certificate chain. SSL/TLS protocols do not require the server to send the CA certificate.

This option is mutually exclusive with -C and --ca-cert.

🌐 SSL/TLS Connection Options 🌐

  • --ssl-protocols=protocols — specifies a range or a comma- or space-delimited list of the SSL/TLS protocols ovsdb-client will enable for SSL/TLS connections. Supported protocols include TLSv1.2 and TLSv1.3. Ranges can be provided in a form of two protocol names separated with a dash, or as a single protocol name with a plus sign. For example, use TLSv1.2-TLSv1.3 to allow TLSv1.2 and TLSv1.3. Use TLSv1.2+ to allow TLSv1.2 and any later protocol. The option accepts a list of protocols or exactly one range. The range is a preferred way of specifying protocols and the option always behaves as if the range between the minimum and the maximum specified version is provided, i.e., if the option is set to TLSv1.X,TLSv1.(X+2), the TLSv1.(X+1) will also be enabled as if it was a range. Regardless of order, the highest protocol supported by both sides will be chosen when making the connection. The default when this option is omitted is TLSv1.2 or later. 🔥
  • --ssl-ciphers=ciphers — bestie, this is where you pick which ciphers ovsdb-client is allowed to vibe with on SSL/TLS connections using TLSv1.2. You write them in OpenSSL cipher string format ✨. If you just… don't pass this at all, the default is DEFAULT:@SECLEVEL=2 (yes, that's literally the whole default string, no cap).
  • --ssl-ciphersuites=ciphersuites — same energy but for TLSv1.3 and later, and this one's in OpenSSL ciphersuite string format 🎀. Omit it and OpenSSL's own default value gets used. She's lowkey self-sufficient like that 💅.

🎀 Other Options 🎀

  • --record[=directory] — ok so this flips the whole process into "recording" mode 🎥. It records all the connections, the data from streams (both Unix domain and network sockets), plus some other important necessary bits, so you can replay the whole thing later. Iconic. The recorded data lives in replay files inside directory. Real talk about paths though: if directory doesn't start with /, it's interpreted as relative to /run/openvswitch. And if you don't give a directory at all? /run/openvswitch it is. Periodt.
  • --replay[=directory] — the sequel 👑. This puts the process in "replay" mode, where it reads info about connections, data from streams (Unix domain and network sockets again), and some other necessary bits directly from replay files instead of using real sockets. The replay files get pulled from the directory you name. Same path rules, fr fr: no leading / means it's relative to /run/openvswitch, and no directory at all means /run/openvswitch gets used. 🫶
  • -h, --help — prints a brief help message to the console. Your lil "what do I do" moment 🌸.
  • -V, --version — prints version information to the console. Gotta know what you're working with 💖.

👀 SEE ALSO 👀

Go read these, iykyk:

✨ that's the whole page, bestie ✨ this little beauty comes from Open vSwitch, version 4.0.0, and it's the ovsdb-client(1) manual — go forth and slay your database connections 💅🦋🍓

📦 where this page comes from