落实fhs标准需以安全、可维护、可观测、可扩展为出发点，对/etc、/var、/usr、/opt、/boot等目录逐层开展用途校验—内容审计—权限/挂载策略优化，确保其真正承载设计角色。
在生产服务器上落实 FHS 标准，不是机械套用目录列表，而是以安全、可维护、可观测、可扩展为出发点，对每个关键目录做“用途校验—内容审计—权限/挂载策略优化”三层检查。核心目标是让目录结构真正支撑运维稳定性，而非仅满足规范条文。
/etc：配置集中化与变更可追溯
该目录应只存放全系统级静态配置文件，禁止存脚本、临时备份或二进制文件。重点检查：
- 确认所有配置文件归属明确（如 /etc/nginx/conf.d/ 下不应混入非 Nginx 的 .conf）
- 禁用 world-writable 权限，常规配置文件应为 644，含敏感信息的（如 /etc/shadow）必须为 600
- 启用 etckeeper 或 Git 管理 /etc，每次修改自动提交并附带操作人与原因
- 避免将服务启动脚本放在 /etc/init.d（已废弃），改用 systemd unit 文件统一管理
/var：分离可变数据与日志生命周期
/var 是生产环境最易失控的目录，需按数据特性分层治理：
- /var/log：设置 logrotate 策略，区分服务日志（如 nginx/access.log）与系统日志（rsyslog 输出），禁止无限增长；敏感日志（如 auth.log）建议加密归档
- /var/lib：数据库、容器运行时（如 /var/lib/docker）、包管理元数据等应各自独立子卷或 LVM 逻辑卷，避免单点填满影响其他服务
- /var/tmp：保留跨重启的临时数据，但需定期清理（如 cron 每日清理 7 天前文件）；严禁用作应用上传缓存目录
- 不推荐将 /var 整体挂载为 tmpfs；若需高性能日志，可单独为 /var/log/journal 配置内存 journal 并持久化同步
/usr 与 /opt：只读性与第三方软件边界
遵循 FHS 中 “/usr 是只读用户数据层次” 原则，生产中应强化隔离：
- /usr 应挂载为 ro（read-only）（除升级期间），防止意外写入破坏系统一致性；所有自定义工具应放入 /usr/local/bin 并确保其所属包管理器可追踪
- /opt 专用于第三方闭源或大型独立应用（如 Oracle、DataStax），每个产品独占子目录（如 /opt/datadog-agent），且禁止在其中创建符号链接指向 /var 或 /etc
- 避免在 /usr/share 或 /usr/lib 下手动添加非发行版来源的库或模板，此类内容应通过容器或 flatpak 等沙箱机制交付
/boot、/dev、/proc、/sys、/run：精简+只读+最小暴露
这些目录直接关联内核与硬件抽象，优化重在收敛风险面：
- /boot 应单独分区（建议 1–2 GB），仅保留当前及上一版 kernel + initramfs；旧内核需定期清理，避免 grub 启动菜单冗长
- /dev 应由 udev 动态管理，禁止手工创建设备节点；对安全敏感环境，可启用 devtmpfs 并禁用 /dev/shm 写入
- /proc 和 /sys 是只读虚拟文件系统，但需限制容器或普通用户对其的挂载能力（通过 mount namespace 或 seccomp 过滤）
- /run 应为 tmpfs 类型，大小设为内存的 5% 左右；关键服务 pidfile、socket、锁文件应严格限定属主和权限（如 /run/nginx.pid → root:root 644）
不复杂但容易忽略：FHS 的价值不在目录是否存在，而在每个目录是否真正承载了它被设计承担的角色。一次彻底的逐目录检查，往往能提前发现配置漂移、权限误配、日志失控等隐患。
