name: 系统配置分析 description: 从sosreport档案中分析系统配置数据，提取操作系统详细信息、安装的软件包、systemd服务状态、SELinux/AppArmor策略和内核参数，以诊断与配置相关的系统问题

系统配置分析技能

这个技能提供了从sosreport档案中分析系统配置的详细指导，包括操作系统信息、安装的软件包、systemd服务和SELinux/AppArmor设置。

何时使用此技能

使用此技能当：

分析/sosreport:analyze命令的系统配置阶段
调查服务故障或错误配置
验证软件包版本和更新
检查安全策略设置（SELinux/AppArmor）
理解系统状态和配置

前提条件

必须将sosreport档案提取到工作目录
必须知道sosreport根目录的路径
了解Linux系统管理

Sosreport中的关键配置数据位置

系统信息:
- uname - 内核版本
- etc/os-release - 操作系统发行版和版本
- uptime - 系统运行时间
- proc/uptime - 以秒为单位的运行时间
- sos_commands/release/ - 发布信息
软件包信息:
- installed-rpms - RPM包（RHEL/Fedora/CentOS）
- installed-debs - DEB包（Debian/Ubuntu）
- sos_commands/yum/ - Yum/DNF信息
- sos_commands/rpm/ - RPM数据库查询
服务状态:
- sos_commands/systemd/systemctl_list-units - 所有单元
- sos_commands/systemd/systemctl_list-units_--failed - 失败的单元
- sos_commands/systemd/systemctl_status_--all - 详细的服务状态
- sos_commands/systemd/systemctl_list-unit-files - 单元文件
SELinux:
- sos_commands/selinux/sestatus - SELinux状态
- sos_commands/selinux/getenforce - 当前执行模式
- sos_commands/selinux/selinux-policy - 策略信息
- var/log/audit/audit.log - SELinux拒绝
AppArmor（如适用）:
- sos_commands/apparmor/ - AppArmor配置
- etc/apparmor.d/ - AppArmor配置文件
系统配置文件:
- etc/ - 系统范围配置
- etc/sysctl.conf 或 etc/sysctl.d/ - 内核参数
- etc/security/limits.conf - 资源限制

实现步骤

步骤1: 分析系统信息

检查操作系统版本和发行版:

if [ -f etc/os-release ]; then
  cat etc/os-release
fi

获取内核版本:

if [ -f uname ]; then
  cat uname
elif [ -f proc/version ]; then
  cat proc/version
fi

检查系统运行时间:

if [ -f uptime ]; then
  cat uptime
elif [ -f proc/uptime ]; then
  # 从proc/uptime解析运行时间（秒）
  awk '{printf "%.2f days

", $1/86400}’ proc/uptime fi


4. **提取关键系统详情**:
- 操作系统名称和版本
- 内核版本
- 系统架构（如x86_64, aarch64等）
- 运行时间（天）

5. **检查过时的内核或操作系统**:
- 比较内核版本与当前稳定版
- 注意系统是否长时间未重启（>365天）
- 识别操作系统版本是否已结束生命周期（EOL）

### 步骤2: 分析安装的软件包

1. **列出安装的软件包**:
```bash
# 对于基于RPM的系统
if [ -f installed-rpms ]; then
  cat installed-rpms
fi

# 对于基于DEB的系统
if [ -f installed-debs ]; then
  cat installed-debs
fi

提取关键软件包版本:

# 重要系统软件包
grep -E "^(kernel|systemd|glibc|openssh|openssl)" installed-rpms 2>/dev/null

# 或使用awk解析软件包名称和版本
awk '{print $1}' installed-rpms | head -20

检查已知问题版本:
- 安全漏洞（如果已知CVE）
- 有错误的软件包版本
- 兼容性问题

识别包管理器问题:

# 检查yum/dnf日志中的错误
if [ -d sos_commands/yum ]; then
  grep -i "error\|fail" sos_commands/yum/* 2>/dev/null
fi

计数软件包并分类:
- 已安装的软件包总数
- 关键软件包版本（内核、systemd、glibc等）
- 最近更新的软件包（如果有时间戳可用）

步骤3: 分析服务状态

列出所有systemd单元:

if [ -f sos_commands/systemd/systemctl_list-units ]; then
  cat sos_commands/systemd/systemctl_list-units
fi

识别失败的服务:

if [ -f sos_commands/systemd/systemctl_list-units_--failed ]; then
  cat sos_commands/systemd/systemctl_list-units_--failed
elif [ -f sos_commands/systemd/systemctl_list-units ]; then
  grep "failed" sos_commands/systemd/systemctl_list-units
fi

检查服务详情:

# 解析失败服务的详细状态
if [ -f sos_commands/systemd/systemctl_status_--all ]; then
  # 提取服务名称及其状态
  grep -E "●|Active:" sos_commands/systemd/systemctl_status_--all | head -50
fi

按状态计数服务:

# 计数运行、失败、非活动服务
if [ -f sos_commands/systemd/systemctl_list-units ]; then
  awk '{print $4}' sos_commands/systemd/systemctl_list-units | sort | uniq -c
fi

识别关键服务故障:
- 系统服务（systemd-*, dbus, NetworkManager）
- 应用程序服务（httpd, nginx, postgresql等）
- 自定义服务

从日志中提取故障原因:

# 对于每个失败的服务，查找相关日志条目
grep -i "failed to start\|service.*failed" sos_commands/logs/journalctl_--no-pager 2>/dev/null | head -20

步骤4: 分析SELinux配置

检查SELinux状态:

if [ -f sos_commands/selinux/sestatus ]; then
  cat sos_commands/selinux/sestatus
fi

获取SELinux模式:

if [ -f sos_commands/selinux/getenforce ]; then
  cat sos_commands/selinux/getenforce
fi

检查SELinux拒绝:

# 在审计日志中查找AVC拒绝
if [ -f var/log/audit/audit.log ]; then
  grep "avc.*denied" var/log/audit/audit.log | head -50
fi

# 或在journald日志中
grep -i "selinux.*denied\|avc.*denied" sos_commands/logs/journalctl_--no-pager 2>/dev/null | head -20

解析拒绝信息:
- 提取被拒绝的操作（读取、写入、执行等）
- 识别源和目标上下文
- 注意受影响的服务

检查SELinux布尔值:

if [ -f sos_commands/selinux/getsebool_-a ]; then
  cat sos_commands/selinux/getsebool_-a
fi

识别SELinux问题:
- SELinux处于宽容模式（可能隐藏错误）
- SELinux禁用（安全问题）
- 频繁的AVC拒绝（策略可能需要调整）
- 上下文不匹配

步骤5: 检查系统配置

审查内核参数:

# 检查sysctl设置
if [ -f sos_commands/kernel/sysctl_-a ]; then
  cat sos_commands/kernel/sysctl_-a
elif [ -d etc/sysctl.d ]; then
  cat etc/sysctl.d/*.conf 2>/dev/null
fi

检查资源限制:

if [ -f etc/security/limits.conf ]; then
  grep -v "^#\|^$" etc/security/limits.conf
fi

# 检查limits.d目录
if [ -d etc/security/limits.d ]; then
  cat etc/security/limits.d/*.conf 2>/dev/null
fi

审查启动参数:

if [ -f sos_commands/boot/grub2-editenv_list ]; then
  cat sos_commands/boot/grub2-editenv_list
elif [ -f proc/cmdline ]; then
  cat proc/cmdline
fi

检查systemd配置:

# 查找systemd配置覆盖
if [ -d etc/systemd/system ]; then
  find etc/systemd/system -name "*.conf" 2>/dev/null
fi

步骤6: 生成系统配置摘要

创建一个结构化的摘要，包括以下部分：

系统信息:
- 操作系统名称和版本
- 内核版本
- 架构
- 系统运行时间
- 上次启动时间
软件包摘要:
- 已安装软件包总数
- 关键软件包版本（内核、systemd、glibc、openssl、openssh）
- 已知问题软件包（如果有）
- 包管理器问题
服务状态:
- 总服务数
- 运行服务计数
- 失败服务计数
- 失败服务列表及原因
- 关键服务状态
SELinux/AppArmor:
- SELinux状态（启用/禁用）
- SELinux模式（执行/宽容/禁用）
- 拒绝计数
- 顶部拒绝操作
- 策略建议
配置问题:
- 内核参数异常
- 资源限制问题
- 启动参数问题
- 配置文件错误

错误处理

缺失配置文件:
- 不同发行版有不同的文件位置
- 某些文件可能未根据sosreport选项收集
- 在摘要中记录缺失数据
包管理器变体:
- 处理RPM和DEB系统
- 考虑不同的包命名约定
- 支持多个包管理器（yum, dnf, apt）
SELinux vs AppArmor:
- 检查使用哪个MAC系统
- 相应分析
- 注意如果两者都存在或都不存在
Systemd vs init:
- 较旧的系统可能使用init而不是systemd
- 检查两者服务管理系统
- 基于存在的内容调整分析

输出格式

系统配置分析应产生：

SYSTEM CONFIGURATION SUMMARY
============================

SYSTEM INFORMATION
------------------
OS: {os_name} {os_version}
Kernel: {kernel_version}
Architecture: {arch}
Uptime: {uptime_days} days ({last_boot_time})

Status: {OK|WARNING|CRITICAL}
Notes:
  - {system_info_note}

INSTALLED PACKAGES
------------------
Total Packages: {count}

Key Package Versions:
  kernel: {version}
  systemd: {version}
  glibc: {version}
  openssl: {version}
  openssh-server: {version}

Status: {OK|WARNING|CRITICAL}
Issues:
  - {package_issue_description}

SYSTEMD SERVICES
----------------
Total Units: {total}
Active: {active_count}
Failed: {failed_count}
Inactive: {inactive_count}

Failed Services:
  ● {service_name}.service - {description}
    Reason: {failure_reason}
    Last Failed: {timestamp}

  ● {service_name}.service - {description}
    Reason: {failure_reason}
    Last Failed: {timestamp}

Status: {OK|WARNING|CRITICAL}
Recommendations:
  - {service_recommendation}

SELINUX
-------
Status: {enabled|disabled}
Mode: {enforcing|permissive|disabled}
Policy: {policy_name}

AVC Denials: {count} denials found

Top Denied Operations:
  [{count}x] {operation} on {target} by {source}
  [{count}x] {operation} on {target} by {source}

SELinux Booleans: {count} custom settings

Status: {OK|WARNING|CRITICAL}
Issues:
  - {selinux_issue_description}

Recommendations:
  - {selinux_recommendation}

KERNEL PARAMETERS
-----------------
Key sysctl Settings:
  vm.swappiness: {value}
  net.ipv4.ip_forward: {value}
  kernel.panic: {value}

Custom Parameters: {count} custom settings found

Status: {OK|WARNING|CRITICAL}
Notes:
  - {kernel_param_note}

RESOURCE LIMITS
---------------
Custom Limits Found: {count}

{user_or_group}  {type}  {item}  {value}

Status: {OK|WARNING}
Notes:
  - {limits_note}

CRITICAL CONFIGURATION ISSUES
-----------------------------
{severity}: {issue_description}
  Evidence: {file_path}
  Impact: {impact_description}
  Recommendation: {remediation_action}

RECOMMENDATIONS
---------------
1. {actionable_recommendation}
2. {actionable_recommendation}

DATA SOURCES
------------
- OS Info: {sosreport_path}/etc/os-release
- Kernel: {sosreport_path}/uname
- Packages: {sosreport_path}/installed-rpms
- Services: {sosreport_path}/sos_commands/systemd/systemctl_list-units
- SELinux: {sosreport_path}/sos_commands/selinux/sestatus
- Audit Log: {sosreport_path}/var/log/audit/audit.log

示例

示例1: 失败服务分析

# 列出失败服务
$ cat sos_commands/systemd/systemctl_list-units_--failed
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● httpd.service          loaded failed failed Apache Web Server
● postgresql.service     loaded failed failed PostgreSQL数据库

# 在日志中查找故障原因
$ grep "httpd.service" sos_commands/logs/journalctl_--no-pager | grep -i "failed\|error"
Jan 15 10:23:45 server systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
Jan 15 10:23:45 server systemd[1]: httpd.service: Failed with result 'exit-code'
Jan 15 10:23:45 server httpd[12345]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80

# 解释: httpd失败，因为端口80已被使用

示例2: SELinux拒绝分析

# 检查AVC拒绝
$ grep "avc.*denied" var/log/audit/audit.log | head -5
type=AVC msg=audit(1705320245.123:456): avc: denied { write } for pid=1234 comm="httpd" name="index.html" dev="sda1" ino=789012 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=0

# 解释:
# - httpd（Web服务器）被拒绝写入访问
# - 目标文件: index.html，上下文user_home_t
# - 问题: Web服务器试图写入用户主目录
# - 解决方案: 修复文件上下文或将文件移动到适当位置

示例3: 软件包版本检查

# 检查特定软件包版本
$ grep "^openssl" installed-rpms
openssl-1.1.1k-7.el8_6.x86_64
openssl-libs-1.1.1k-7.el8_6.x86_64

$ grep "^kernel" installed-rpms
kernel-4.18.0-425.el8.x86_64
kernel-4.18.0-477.el8.x86_64
kernel-core-4.18.0-425.el8.x86_64
kernel-core-4.18.0-477.el8.x86_64

# 解释:
# - OpenSSL版本1.1.1k（检查已知CVE）
# - 安装多个内核（便于回滚）
# - 当前内核是4.18.0-477（来自uname）

有效分析技巧

检查服务依赖: 失败服务可能是由于依赖故障
与日志关联: 服务故障通常在日志中有详细错误
验证配置: 检查服务配置文件是否存在语法错误
考虑时间: 服务何时失败？与系统事件关联
SELinux上下文重要: 文件上下文必须与策略期望匹配
软件包版本: 与已知好/坏版本比较
运行时间意义: 非常长的运行时间可能意味着错过安全更新

常见配置模式和问题

服务依赖故障: ServiceB失败，因为ServiceA未运行
端口冲突: 服务无法绑定 - 端口已被使用
权限拒绝: 服务无法访问所需的文件/目录
SELinux阻止: 服务被SELinux策略拒绝访问
缺失依赖: 所需的软件包未安装
配置错误: 配置文件中的语法错误
资源限制: 服务达到ulimit（打开文件、进程等）
过时内核: 运行的内核与安装的软件包不匹配

配置问题严重性分类

问题类型	严重性	影响
关键服务失败	高	核心功能不可用
可选服务失败	低	非必要功能不可用
SELinux宽容模式	警告	安全性降低，隐藏问题
SELinux禁用	关键	无强制访问控制
内核非常过时	高	缺少安全修复
EOL操作系统版本	关键	无安全更新
许多AVC拒绝	警告	策略可能需要调整

另请参见

日志分析技能: 用于详细的服务故障日志分析
资源分析技能: 用于资源限制问题
网络分析技能: 用于网络服务配置