Send an Existing sudo I/O Log to a Remote Server

You will finish with a checked command line for sending an existing sudo I/O log to a remote sudo_logsrvd server, including the TLS files and restart information you need. The installed command here is from sudo 1.9.15p5, package version 1.9.15p5-3ubuntu5.24.04.3. Allow about fifteen minutes for a first transfer, plus time to confirm the server-side result.

You need the sudo package, a readable I/O log path, the destination server details and permission to use the client certificate and private key if TLS is enabled. Reading a protected log may require elevated privileges, but sudo_sendlog itself does not make a normal transfer a root operation.

1. Confirm the installed command

Check the binary, version and option syntax before preparing a transfer. These are ordinary, read-only commands:

$ command -v sudo_sendlog
/usr/sbin/sudo_sendlog
$ sudo_sendlog --version
sudo_sendlog version 1.9.15p5
$ sudo_sendlog --help
sudo_sendlog - send sudo I/O log to remote server
... 

The help output is abbreviated above because the exact layout is not part of the interface. The important shape is sudo_sendlog [options] path: the final argument is the existing I/O log path, not a server URL.

2. Check the log path without sending it

Use a path that already exists and that contains the I/O log produced by sudoers. Inspect it without modifying the log:

$ LOG_PATH='/path/to/existing/iolog'
$ test -r "$LOG_PATH" && echo 'log path is readable'
log path is readable
$ ls -ld -- "$LOG_PATH"
drwx------ ... /path/to/existing/iolog

The final listing is illustrative: permissions, ownership and whether the path is a file or directory depend on your sudoers logging setup. Keep the quoted placeholder until you have replaced it with a real path. If the check fails, fix the path or access rights first. Do not use sudo automatically; use elevated privileges only when your access policy permits reading that log.

A missing path fails locally before a connection is attempted:

$ sudo_sendlog /tmp/does-not-exist-sudo-iolog
sudo_sendlog: /tmp/does-not-exist-sudo-iolog: No such file or directory
$ printf 'exit status: %s\n' "$?"
exit status: 1

That check is safe because no remote transfer can start. Replace the temporary path with your real log before continuing.

3. Set the destination and TLS files

The default destination is host localhost on port 30344. Set --host and --port when the log server is elsewhere. With TLS, --cert and --key are required, and both files are PEM format. The server certificate is verified by default against the system certificate database:

$ LOG_HOST='logs.example.net'
$ LOG_PORT='30344'
$ CERT_FILE='/etc/sudo/client-cert.pem'
$ KEY_FILE='/etc/sudo/client-key.pem'
$ CA_BUNDLE='/etc/ssl/certs/ca-certificates.crt'
$ sudo_sendlog --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" --ca-bundle "$CA_BUNDLE" \
    "$LOG_PATH"

The command above is ready only after each placeholder has been replaced and the server is expecting that client certificate. --ca-bundle is optional when the system database already trusts the server certificate. Protect the private key with the permissions required by your local policy and do not paste its contents into a shell command or support ticket.

--no-verify disables server certificate verification. That removes the check that the certificate is valid and matches the host name or IP address. Treat it as a controlled diagnostic for an isolated test, never as the normal repair for a TLS failure.

4. Send one disposable log

Before a production transfer, confirm the server endpoint, certificate identity and intended log path with the log-server administrator. Then run the same command with the real values:

$ sudo_sendlog --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" --ca-bundle "$CA_BUNDLE" \
    "$LOG_PATH"
$ printf 'exit status: %s\n' "$?"
exit status: 0

Status 0 means the client completed its operation successfully. It does not replace checking the remote server for the new log, its command metadata and its I/O records. The command can contact the server and change remote state, so do not repeat it against a production log merely to see whether the syntax is valid.

There is no local rollback command in this workflow. If the wrong log was sent, use the log server's documented retention or deletion procedure, with its normal approval and audit trail. Keep the original local log until the remote copy has been checked.

5. Exercise event-only or rejection testing safely

--accept-only sends only the accept event and no associated I/O. --reject REASON sends a reject event and no I/O, even though the command was accepted locally. These options are for testing server event handling, not for changing what happened in the original sudo session:

$ sudo_sendlog --accept-only --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" "$LOG_PATH"
$ sudo_sendlog --reject 'test event only' --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" "$LOG_PATH"

Use these only with a test log and a server where synthetic events are expected. They still create remote records. The short forms are -A and -R.

6. Stop and resume a partial transfer

For controlled testing, --stop-after seconds,nanoseconds stops sending when that elapsed point is reached and closes the connection. The resulting partial log can be restarted:

$ sudo_sendlog --stop-after 30,0 --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" "$LOG_PATH"
$ sudo_sendlog --restart 30,0 --iolog-id 'REMOTE_IOLOG_ID' \
    --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" "$LOG_PATH"

The restart point is normally the last commit point received from the server, not an arbitrary wall-clock timestamp. The server supplies the remote I/O log ID when it creates the remote log. Do not invent either value. The --iolog-id option may only be used with --restart; if the connection was interrupted, obtain the last accepted commit point and ID from the server's records.

7. Use parallel testing only on a test service

--test NUMBER opens the specified number of simultaneous connections and sends the selected I/O log on each one. This is a performance test, not a faster production upload:

$ sudo_sendlog --test 3 --host "$LOG_HOST" --port "$LOG_PORT" \
    --cert "$CERT_FILE" --key "$KEY_FILE" "$LOG_PATH"

Use a disposable log, an agreed connection limit and a server intended for load testing. A large number can create many remote records and consume server resources. Stop and investigate rather than increasing the number when a transfer fails.

Common failure checks

• A missing path or permission error is local. Check ls -ld and test -r before changing server options.
• A TLS failure usually needs the correct certificate, private key, CA trust and host name. Check each path and the server's certificate identity.
• A connection refusal usually means the host or port is wrong, the server is not listening, or a firewall is blocking the connection. Confirm those facts with the administrator.
• A restart needs both the server-issued I/O log ID and the last server commit point. Starting a new transfer is not equivalent to resuming one.