17. Customizing the sos report command.

17. Customizing the sos report command.

We know that sos command-line options can be overwhelming, to say the least. A single sos report execution can involve dozens of flags, plugin toggles, size limits, and behavioral switches. Remembering the correct combination—especially under pressure during a production incident—is impractical, even for experienced administrators.

Fortunately, there is a structured and reliable way to eliminate this complexity: centralizing those decisions in a configuration file. Instead of repeatedly crafting long command invocations, you can define a consistent, repeatable baseline that sos report will automatically follow every time it runs.

This is where /etc/sos/sos.conf becomes essential. It acts as a control layer that standardizes how diagnostic data is collected across systems, environments, and teams. Whether the goal is to minimize report size, avoid sensitive data, or ensure comprehensive data capture for support cases, this file allows those requirements to be enforced without relying on memory or manual input.

By shifting from ad-hoc command usage to configuration-driven behavior, you reduce errors, improve consistency, and make sos report far more predictable—especially in automated or large-scale environments.

Understanding /etc/sos/sos.conf

Overview

The /etc/sos/sos.conf file is the primary configuration file for the sos utility (formerly known as sosreport). It defines default behaviors, plugin settings, and runtime options used when generating system diagnostic reports.

Rather than repeatedly specifying command-line flags, this file allows administrators to enforce consistent collection policies across systems.

Purpose

The file serves three main purposes:

  1. Default Configuration Source Provides baseline options automatically applied to every sos report run.

  2. Plugin Behavior Control Enables, disables, or customizes plugins that collect subsystem data.

  3. Policy Enforcement Standardizes what data is collected, how much, and under what constraints (important in enterprise environments).

How It Works

When sos report runs:

  1. It loads built-in defaults.

  2. It reads /etc/sos/sos.conf (if present).

  3. It applies any command-line overrides (highest priority).

Precedence order:

Command-line options > sos.conf > built-in defaults

This means sos.conf acts as a middle layer—ideal for system-wide defaults without restricting ad-hoc overrides.

File Structure

The file uses an INI-style format with sections:

[global]
key = value

[plugin_options]
option = value

Common Sections

  • [global] General sos report behavior

  • [report] Options scoped only to report generation. Only apply to sos report and not to sos collect for example.

  • [plugin_options] Plugin-specific configurations

Key Configuration Options

Global Settings

Option

Description

log_size

Limits size of collected logs (MB)

verbosity

Controls output verbosity

batch

Run non-interactively

tmp_dir

Temporary working directory

compression_type

Compression method (e.g., gzip, xz)

skip_plugins

Disable the specified plugin(s). Multiple plug-ins may be specified in a comma-separated list. Note that skip_plugins and only_plugins are mutually exclusive only_plugins takes precedence.

only_plugins

Enable the specified plugin(s) only (all other plugins should be disabled). Note that skip_plugins and only_plugins are mutually exclusive only_plugins takes precedence.

clean

Enables obfuscation, masking sensitive data like IPs, hostnames, etc. Note that this option is CPU intensive and takes longer that the actual data gathering phase.

threads

Specify the number of threads sos report will use for concurrency. Defaults to 4.

upload-user

Specify the username (email) to use for authentication with the sos report management server

upload-pass

Specify the password to use for authentication with the sos report management server

upload-url

Specify the URL of the sos report management server

Plugin Control

You can explicitly disable or enable plugins:

[global]
# Disable this specific plugins.
skip-plugins = apache,mysql
[global]
# Enable this specific plugins.
only-plugins = networking,system

Plugin-Specific Options

Each plugin may expose its own tunables. Example:

[plugin_options]
networking.traceroute = yes
networking.ping_count = 5

What Should You Put in It?

The contents depend on your operational goals. Typical use cases:

1. Production Systems (Controlled Collection)

[global]
batch = yes
log-size = 50
compression-type = xz
skip-plugins = debug,logs

Goal:

  • Limit data volume

  • Avoid sensitive or excessive logs

  • Ensure automation compatibility

2. Support / Troubleshooting Systems

[global]
verbosity = 2
log-size = 200

Goal:

  • Maximum data collection

  • Useful for vendor support cases

3. Security-Conscious Environments

[global]
batch = yes
skip-plugins = ssh,logs

[plugin_options]
ssh.collect_keys = no

Goal:

  • Avoid collecting sensitive credentials or logs

4. Automation / CI / Fleet Environments

[global]
batch = yes
tmp-dir = /var/tmp/sos
compression_type = gzip
skip-plugins = system,networking

Goal:

  • Deterministic, fast, minimal reports

  • Suitable for large-scale automated collection

Example Full Configuration (with Encryption, Obfuscation, and Upload)

[global]
# Enable batch mode to skip interactive prompts
batch = true
# Set the number of threads for data collection
threads = 4
verbosity = 1
log-size = 100
# xz is often the default, but you can explicitly ensure it here
compression-type = xz
tmp-dir = /var/tmp/sos
skip-plugins = logs, debug

[report]
# --- ENCRYPTION ---
# Encryption Key to encrypt the resulting archive. 
# Provide the same Decrypt Key configured in your sos-vault account (“Settings → Keys”)
# for automatic unpack to work.
encrypt-pass = ***ENCRYPTION PASSWORD***

# --- OBFUSCATION ---
# Enables the 'clean' functionality during the report run.
# Masking sensitive data like IPs, hostnames, etc. 
clean = true
# Optional: Path to a custom keyword file for extra obfuscation
# keywords = /path/to/my_keywords.txt

# --- UPLOAD SETTINGS ---
# The destination URL for the report
upload-url = https://sos-vault.com/api/upload

# Credentials for the sos report management system (SRMS)
# Your email address
upload-user = email@example.com

# The Upload Key generated in your sos-vault account (“Settings → Keys”) 
upload-password = ***UPLOAD PASSWORD***

upload-method = post

[plugin_options]
networking.traceroute = yes
networking.ping_count = 3

Practical Behavior Example

Without sos.conf:

$ sudo sos report -q --clean --batch --case-id "CASE_ID" --encrypt-pass "***ENCRYPTION PASSWORD***" --upload-url "https://sos-vault.com/api/upload" --upload-user "email@example.com" --upload-pass "***UPLOAD PASSWORD***" --upload-method post

With sos.conf:

$ sudo sos report --case-id "CASE_ID"

Same behavior, because defaults are preconfigured.

Important Considerations

  1. Since sos.conf may contain sensitive data, always restrict access with chmod 600 /etc/sos/sos.conf and ensure the file is owned by root.

  2. Plugin Availability. Not all plugins exist on all systems. Missing plugins are ignored.

  3. Sensitive Data. Some plugins may collect: Logs with credentials.

  • SSH configs Network details

  • Always review with

sudo sos report --list-plugins
  1. Performance Impact. Large collections (e.g., high log_size, all plugins enabled) can:

    • Increase runtime.

    • Consume CPU/disk.

    • Generate very large archives

  2. Overrides Still Apply. Even with strict defaults, operators can override:

sudo sos report --no-logs

Where This Fits in Your Workflow

For environments like sos-vault, /etc/sos/sos.conf is particularly useful to:

  • Standardize incoming reports

  • Reduce unnecessary data ingestion

  • Control sensitive data exposure before upload

  • Optimize report size for storage and analysis

Summary

/etc/sos/sos.conf defines default behavior for sos report

  • Uses an INI-style configuration format

  • Allows control over:

  • Global options

  • Plugin selection

  • Plugin-specific parameters

  • Acts as a policy layer between built-in defaults and CLI overrides

Proper use of this file improves consistency, security, and efficiency in diagnostic data collection across systems.