# 🔧 Deep Dive into sosreport: Understanding the Data Pack Layout in Fedora & RHEL **By Suraj Rajendra Patil (Fedora ID: suraj522)** ***🧰 What is sosreport?*** sosreport is a powerful command-line utility used on Fedora, Red Hat Enterprise Linux (RHEL), CentOS, and other RHEL-based systems to collect a comprehensive snapshot of the system's configuration, logs, services, and state. It is primarily used for diagnosing issues, especially during support cases with Red Hat or other vendors. When executed, sosreport runs a series of modular plugins that collect relevant data from various subsystems like networking, storage, SELinux, Docker, and more. The resulting report is packaged into a compressed tarball, which can be securely shared with support teams to expedite troubleshooting. In essence, sosreport acts as a black box recorder for Linux — capturing everything from system logs and kernel messages to active configurations and command outputs — helping support engineers trace problems without needing direct access to the system. ***🛠️ How to Generate a sosreport*** To generate a sosreport on Fedora, RHEL, or CentOS, run the following command as root or with sudo: ``` sudo sosreport ``` This command collects system configuration, logs, and command outputs using various plugins. After a few minutes, it generates a compressed tarball in /var/tmp/ (or a similar location), typically named like: ``` sosreport-hostname-20250623-123456.tar.xz ``` You may be prompted to enter a case ID or other metadata, depending on your system configuration or support workflow. When an `sosreport` is generated on a Fedora, RHEL, or CentOS system, it produces an encrypted and compressed tarball that contains a detailed snapshot of the system's health and configuration. Inside this archive lies a well-organized structure, reflecting the myriad Linux subsystems from which the data is collected. Exploring a `sosreport` is challenging due to the sheer volume of logs, configuration files, and system command outputs it contains. However, understanding its layout is key for support engineers and sysadmins to quickly locate and interpret crucial diagnostic information. --- ## 📁 sosreport Directory Layout When the tarball is unpacked, the directory structure typically resembles this: ```bash . ├── ./boot ├── ./etc ├── ./lib -> usr/lib ├── ./opt ├── ./proc ├── ./run ├── ./sos_commands ├── ./sos_logs ├── ./sos_reports ├── ./sos_strings ├── ./sys ├── ./usr ├── ./var └── ./EXTRAS ``` ### Core Breakdown: * Most directories mimic a standard Linux root filesystem and primarily contain configuration files. * The directories that **don’t** appear in a regular root filesystem include: * `sos_commands` * `sos_logs` * `sos_reports` * `sos_strings` * `EXTRAS` --- ## 🔍 Key Directories in Detail ### 🔊 `sos_commands/` This contains output from commands executed by each plugin. Its structure is plugin-specific: ```bash ./sos_commands/ ├── apparmor/ ├── docker/ ├── memory/ ├── networkmanager/ ├── process/ │ ├── lsof_M_-n_-l_-c │ ├── pidstat_-p_ALL_-rudvwsRU_--human_-h │ ├── ps_auxwwwm │ └── pstree_-lp ... ``` Each file name matches the Linux command used, with all options. The contents are the actual command output, making the plugin behavior transparent. --- ### 📊 `sos_reports/` This directory contains multiple formats that index and summarize the entire sosreport: * `sos.json`: A machine-readable index of all collected files and commands. * `manifest.json`: Describes how sosreport executed – timestamps, plugins used, obfuscation done, errors, etc. * HTML output for easy browsing via browser. --- ### 📃 `sos_logs/` Contains logs from the execution of `sosreport` itself. * `sos.log`: Primary log file that highlights any errors or issues during data collection. --- ### 📰 `sos_strings/` * Contains journal logs for up to **30 days**, extracted using `journalctl` * Can be quite large, especially on heavily used systems * Structured into subdirectories like `logs/` or `networkmanager/` --- ### 🔒 `EXTRAS/` This is not a default part of a `sosreport`. It is created by the `sos_extras` plugin and used to collect any **custom user-defined files**. --- ## 🚀 Why This Layout Matters * **Speed**: Directories are logically grouped, helping engineers drill down without manually parsing GBs of log files. * **Traceability**: Knowing where each file came from and what command produced it enhances reproducibility. * **Automation**: Tools like `soscleaner` or `sos-analyzer` rely on this structure for automated diagnostics. --- ## ✅ Final Thoughts While `sosreport` is a powerful diagnostic tool, its effectiveness hinges on understanding its structure. With familiarity, engineers can isolate root causes of failures, uncover misconfigurations, and collaborate more efficiently with support teams. If you haven't yet opened one up manually, try it — there's a lot to learn from the inside!