原文:Linux System Administration for the 2020s
协议:CC BY-NC-SA 4.0
九、安全
安全性是作为 Linux 系统管理员可以讨论的最重要的主题之一。所有组织都至少需要最低限度的安全性,以避免被寻找简单目标的随机黑客暴露或破坏。
像银行这样的大型组织需要高度重视安全性,并且需要不惜一切代价确保它们受到保护。这将包括确保系统被强化到第 n 级。
本章将重点介绍如何加强安全性,以及如何检查系统以确保它们不仅符合良好的安全实践,还符合合规性法规。在本章中,我们将探索开源社区中可以用来构建安全平台的不同工具,以及如何验证系统是否尽可能安全。
最后,我们将讨论 DevSecOps 以及文化的改变如何提高安全性。我们将看看今天的 DevSecOps 实践如何改进保护 Linux 系统的过程。
Linux 安全性
构建和配置安全 Linux 环境的传统方法是利用防火墙、SELinux,在某些情况下还会使用防病毒软件。
然而,今天我们在我们的资产中部署的不仅仅是标准的 Linux 系统。有容器映像、虚拟机映像和云实例映像等等。如何检查这些映像上的漏洞,以及如何检查用于运行您组织的应用程序的第三方软件?
作为一名 Linux 系统管理员,您如何在不妨碍日常工作的情况下管理这些风险呢?有什么工具可以简化这一流程,并确保发放到您遗产中的所有东西都是安全的?
让我们先来看看标准的 Linux 安全性,它可以在您的 Linux 发行版上轻松配置。然后看看文化的改变和新的工具如何为新的构建和部署简化这个过程。
标准 Linux 安全工具
开箱即用,大多数 Linux 发行版都已经安装了工具,或者可以安装工具,这将允许您在基本级别上保护平台。常见的工具有防火墙、SELinux 和一些入侵检测。
防火墙
对 Linux 防火墙的基本描述是,Netfilter 工具集允许在 Linux 内核模块级别访问网络堆栈。
要为 Netfilter 配置规则集,您需要一个规则集创建工具。默认情况下,所有企业 Linux 系统都安装了防火墙规则集工具,某些云映像版本除外。这些图像往往更加精简,并不总是包括防火墙工具。这是因为保护应该在云协调层处理。
大多数 Linux 发行版安装了 iptables 或 firewalld 作为它们的规则集工具。这两个选项都有高度的配置,可以用来保护您的 Linux 系统。
Iptables
以前的 Linux 发行版和一些决定不继续使用 systemd 的发行版仍然使用防火墙规则集配置工具 iptables。Iptables 可能会变得很复杂,但是如果你有一个基本的理解,并且知道如何检查一个规则是否已经被启用,那么你就已经做得很好了(表 9-1 )。
表 9-1
基本 iptables 命令
|LVM 司令部
|
描述
|
| — | — |
| iptables -L -n
| 以数字格式列出所有链中的所有规则 |
| iptables --help
| 关于可用参数的帮助 |
| iptables -A INPUT -p tcp --dport 22 -j ACCEPT
| 添加 tcp 端口 22 的示例 |
| iptables -F
| 刷新 iptables 配置中的所有规则 |
| iptables-save > /etc/iptables/rules.v4
| 在 Debian/Ubuntu 上保存 iptables 配置 |
| iptables-save > /etc/sysconfig/iptables
| 在 RHEL 上保存 iptables 配置 |
防火墙!防火墙
如果您使用的是企业版的 Linux,那么您很可能会使用 systemd。使用 systemd,您将使用 firewalld 作为 Netfilter 的规则集配置工具。
Firewalld 的设计比 iptables 更简单易用。像 iptables 一样,Firewalld 有一些所有 Linux 系统管理员都应该知道的命令。表 9-2 列出了一些需要记住的基本命令。
表 9-2
基本防火墙命令
|LVM 司令部
|
描述
|
| — | — |
| firewall-cmd --list-all
| 列出当前配置的所有规则 |
| firewall-cmd --add-port=80/tcp --permanent
| 打开 tcp 端口 80 |
| firewall-cmd --add-service=ssh --permanent
| 通过引用服务名打开端口 22 |
| firewall-cmd --help
| 帮助 |
| firewall-cmd --reload
| 重新加载防火墙以启用新规则 |
Tip
如果可能,请使用 firewall-cmd,并且永远不要禁用防火墙服务。相反,了解需要哪些端口并打开这些端口,而不是让整个系统都打开。
防火墙
另一种在大多数 Linux 发行版上使用的安全措施是 SELinux,它最初是由美国国家安全局概念化和开发的。
总之,SELinux 是一个 Linux 内核安全模块,它允许访问 Linux 操作系统的某些部分。
如果你把你的 Linux 系统想象成一个安全的建筑,那么外面的栅栏和墙、大门、主门和窗户就是你的防火墙。安全建筑的内部及其房间和设施由值班保安人员管理。安全人员的工作是检查谁有权使用什么房间和什么设施。在这种情况下,安全团队将充当 SELinux。
正如你需要理解你的 Linux 防火墙的基础一样,你也需要理解 SELinux 的基础(表 9-3 )。现在,您需要知道的是如何启用、禁用和恢复基本配置。更复杂的配置会随着经验而来。
表 9-3
基本 SELinux 命令
|LVM 司令部
|
描述
|
| — | — |
| getenforce
| 显示当前 SELinux 状态 |
| setenforce 0
| 暂时禁用 SELinux |
| setenforce 1
| 临时启用 SELinux |
| /etc/selinux/config
| 配置 SELinux 的永久状态 |
| restorecon -Rvv /path/to/file
| 通过目录上的当前标签恢复 SELinux 配置集 |
有两种入侵检测可用于任何服务器资产:基于主机的入侵检测和基于网络的入侵检测。出于本书的目的,我们将只讨论我们可以在我们的 Linux 平台上部署什么。
基于主机的入侵检测
大多数 Linux 系统管理员经常忽略并且没有配置某种形式的基于主机的入侵检测。在大多数 Linux 企业发行版上,至少应该安装以下选项之一。如果没有,你可能需要从社区库安装,如 EPEL。
表 9-4 列出了一些可用于基于主机的入侵检测的选项。
表 9-4
入侵检测选项
|工具名称
|
描述
|
| — | — |
| Aide
| 标准存储库提供了高级入侵检测环境 |
| Fail2ban
| 另一个流行的入侵检测解决方案,但是需要从某些发行版上的 EPEL 库安装 |
| Samhain
| 完整性检查器和主机入侵检测系统 |
Warning
当从社区存储库安装时,如果您安装第三方工具,请务必咨询您的 Linux 供应商是否支持该平台。
推荐的 Linux 安全配置
如果您需要快速构建一个 Linux 系统,并希望确保它尽可能安全,那么您至少应该配置以下内容。
禁用 Root 登录
通过编辑 sshd_config,禁用通过 ssh 登录到 root 的功能。您仍然可以通过控制台登录,或者如果您需要通过单用户模式来拯救您的系统。
最小安装
用选择的最小软件包安装您的 Linux 服务器。最好从一个基本的构建开始,然后添加您需要的包。在构建安全的 Linux 服务器时,少即是多。
磁盘分区
表 9-5 列出了所有应该配置相应挂载选项的独立磁盘分区。
表 9-5
磁盘布局和装载选项
|唱片
|
装载选项
|
| — | — |
| /var
| |
| /var/log
| |
| /var/log/audit
| |
| /var/tmp
| 挂载到与/tmp 相同的磁盘上 |
| /tmp
| nodev, nosuid, noexec |
| /home
| 转移 |
| /dev/shm
| nodev, nosuid, noexec |
| removable media
| nodev, nosuid, noexec |
磁盘加密
仅当服务器可以轻松带出数据中心或服务器机房时,才考虑使用磁盘加密。这将适用于笔记本电脑或任何便携式系统。一个常用的磁盘加密工具是 LUKS。
没有桌面
不要安装 Linux 桌面或“X Windows 系统”如果已安装,请删除桌面和“X Windows 系统”软件包。
Remember
在尝试删除包之前,请将运行级别设置为 3。
加密网络通信
尽可能使用加密通信。打开 ssh 连接时使用证书或密钥。使用安全的方法挂载网络文件系统,无需传输明文密码。
删除和禁用不安全或未使用的服务
删除潜在的不安全软件包,如 telnet 或 ftp,并使用安全版本,如 sftp。还建议删除或禁用未使用的服务。
应用更新和修补内核
听起来显而易见,但是请确保您的 Linux 系统已经被修补到最新的版本。一旦你确认你的系统可以很好的使用新的内核,升级内核并移除旧的内核。
SELinux 和防火墙
确保 SELinux 和 Linux 防火墙都已启用,并且有必要的配置。
改进的身份验证配置
如果强制使用本地用户,请为 Linux 用户帐户配置密码时效,确保不能使用以前使用过的密码,并在登录失败后锁定帐户。最后,确保没有帐户的密码为空。
如果可能的话,使用中央用户认证服务,比如使用 Kerberos 认证的 LDAP 服务器。
检查打开的端口
检查当前打开了哪些端口,并验证是否有任何端口不应该打开。检查本地主机上打开了哪些端口的一个非常有用的命令如下:
# nmap -sT -O localhost
全局可写文件
检查是否有任何可写的文件或目录。检查这一点的有用命令如下:
# find /dir -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
不属于任何人的文件
Linux 系统上不属于任何人的任何文件都可能带来潜在的安全风险。使用以下命令检查任何文件:
# find /dir -xdev \( -nouser -o -nogroup \) -print
美国学术团体委员会
使用 ACL 为需要访问系统的用户配置对磁盘和文件的特定权限。不要为非管理员用户打开系统范围的权限。
将日志发送到中央日志记录服务
配置所有的 Linux 系统,将日志发送到中央日志服务。这将确保您在清除日志之前跟踪所有登录尝试。
入侵检测
安装和配置入侵检测工具,如 Aide 或 Fail2ban。如果使用 Aide,请确保将数据库复制到被监控的服务器之外的安全位置。这可以在以后用于比较目的。
应用服务器安全性
如果将 Linux 系统用作 web 服务器或应用程序服务器,请确保为安全通信配置了证书。
发展合作
所有这些安全措施都取决于应用它们的人。如果一个组织没有接受安全不仅仅是安全团队的责任这一事实,那么当出现安全漏洞时,那些令人讨厌的人就会有机可乘。这就是为什么文化安全观必须有所发展。
过去几年中,组织文化上最大的变化之一就是这样。每个人都对安全负责。
这是什么?
同样,DevOps 是一套实践和工具,旨在通过采用开发实践将开发和运营团队聚集在一起,DevSecOps 旨在使组织内的每个人都使用安全实践和工具(图 9-1 )。基本上,它代表着每个人都对安全负责。
图 9-1
维恩图,不同的团队聚集在一起创建开发团队
每个人都对安全负责
正如每个人都需要通过社会工程和了解物理安全的简单安全实践来警惕潜在的攻击者一样,DevSecOps 努力让每个人在技术工作的各个方面都考虑安全问题。
从部署新代码或构建新系统,所有东西在发布之前都需要通过安全门。从互联网上拉第三方内容需要在发布前进行扫描和测试。
安全需要被视为一个不断发展的实体。需要检测威胁,发现问题需要做平台补救。安全管理流程应遵循类似于图 9-2 所示的流程。
图 9-2
安全的循环
扫描环境,检查扫描结果,补救问题,观察所需的更改,最后应用更改以避免重复出现问题。
工具
Linux 系统管理员、开发人员和用户需要意识到,添加到 Linux 资产中的任何新东西都必须满足安全需求。手动运行扫描和测试不会支持这种文化转变,并且会将您置于安全被忽视的境地。
所有这些安全检查都需要以自动化的方式完成。当检测到安全问题时,应该停止该过程并进行补救。例如,如果构建一个新的容器映像,构建一个不安全的容器映像和浪费存储空间是没有意义的。最好停止,修复问题,然后重新运行构建。
安全门
整合 DevSecOps 实践的一个好方法是将安全门构建到管道工具中,如 Jenkins 或 Tekton(图 9-3 )。
图 9-3
代码被推送、检查,并与提取的映像一起烘焙
将用于部署新容器的结果映像在部署之前进行检查。如果安全门发现一个漏洞,该过程就会停止,部署就会失败,从而防止安全漏洞被部署到实际环境中。
任何自动化工具都可以用来包括安全门。例如,Ansible Tower 能够利用工作流。Red Hat Satellite 或 Uyuni 有一个自动化的构建过程,也可以使用。
第三方工具
强烈建议您的安全门使用第三方工具来扫描和检查代码。使用 SonarQube 这样的产品能够扫描漏洞和检查代码的语法问题。
系统合规性
系统符合标准有许多原因。能够存储一个人的信用卡详细信息的能力决定了应该如何在金融组织内保护系统。不这样做将意味着经济处罚或更糟。
要使系统兼容,需要遵循一些强化要求。这些要求需要应用于所有系统,并在审计时间到来时提供证据。
系统硬化
强化 Linux 系统是一个消除系统中任何潜在攻击面的过程。
潜在的攻击者可以暴露系统的许多方面。例如,最近发现的一个漏洞使得非 root 用户能够利用 sudoedit 命令中的漏洞。该漏洞允许用户在未经授权的情况下运行特权命令。
作为 Linux 系统管理员,我们能做的最重要的事情就是找到这些类型的漏洞,并在暴露之前修复它们。当构建数百个甚至数千个系统时,减少问题发生的几率甚至更为重要。这就是为什么系统加固和系统漏洞扫描对于确保您的系统在上线前尽可能安全至关重要。
硬化标准
现在有许多标准可以用来强化您的 Linux 资产。使用的两种主要方法是 CIS 和 STIGs。两者非常相似,很大程度上是因为一个人能做的安全调整是有限的。然而,这两者都是确保您的平台达到良好标准的良好起点。
对于不同的组织,还必须遵循一些其他标准,例如针对美国联邦机构的 NIST 800-53 和针对金融组织或任何希望存储信用卡/借记卡详细信息的组织的 PCI DSS。这些标准通常应用于 STIGs 或 CIS 指南之上。
互联网安全中心
如果您过去曾经做过系统加固,那么您可能已经熟悉了 CIS 标准。CIS 是一个非营利组织,旨在尽可能确保互联世界的安全。CIS 向任何需要的人免费提供他们的安全指南,并且还提供付费服务,CIS 可以提供已经加固的资源,如系统映像。
作为 Linux 系统管理员,下载强化指南并按照步骤保护您的平台就足够了。指南写得很好;它们解释了安全配置的用途,以及如何在发现平台存在漏洞时进行补救。指南甚至给你运行的命令。
过去,我通过复制和粘贴这些指南中的命令来编写 shell 脚本。今天,有更好的方法可以做到这一点,我将在本章中简要介绍。
安全技术实施指南
与 CIS 非常相似,你也可以遵循 STIG 指南来强化你的平台。这些指南也是免费的,但是更符合美国政府的要求。
STIG 指南也不像独联体指南那样多种多样。与 CIS 相比,STIG 指南可能没有针对基于社区的平台或应用的指南。如果 CIS 有可以使用的专用指南,则必须使用通用指南。
强化 Linux
有几种方法可以强化您的 Linux 系统。
手动配置
我加固 Linux 系统的最后一种方法是手动操作。光是需要遵循的硬化步骤的数量就会让你忙得不可开交。大多数硬化指南都超过了 100 页,远非引人入胜的读物。
如果需要手工强化一个系统,那么你可以遵循的最好的工具就是因特网上的强化指南,比如 CIS。
每种不同的可用强化指南都附带了用于确定系统是否存在漏洞的命令,如果漏洞确实存在,还会提供补救命令。在这种情况下,你的朋友会复制并粘贴,直到你看完这本内容丰富的指南。
我的建议是尽可能地推迟手动操作。它所花费的时间将远远超过建立下一个强化系统的方法所花费的时间。
自动化
自动化是你的朋友。互联网上充斥着像您这样需要强化系统的 Linux 系统管理员编写的内容。很有可能你会找到一些能完全按照你的意愿行事的天使或木偶。你还将获得过程可重复的额外好处,当你的老板告诉你强化另外五个系统时,这将非常方便。
Tip
记得搜索那些互联网资源星系,如 Ansible Galaxy 或 Puppet Forge 的内容。
OpenSCAP
如果您需要从一个不同的已经加固的系统中复制配置,那么从互联网下载的自动化可能会让您稍感失望。可能有一个特定的系统具有特定的强化,但由于某种原因并没有应用所有的强化。
那么,您将如何运行标准强化来适应相同的设置呢?
对于这个用例,您可以使用 OpenSCAP。OpenSCAP 能够扫描一个或多个系统,并生成系统配置报告。可以将此配置与另一个系统进行比较,并运行后续报告来列出差异。
OpenSCAP 的惊人之处在于,它还可以生成 Ansible 或 Puppet 代码来弥补这些差异,使您不必编写自己的自动化代码。
OpenSCAP 可以使用现成的 CIS 配置文件运行,也可以使用其他配置文件。大多数(如果不是全部)将通过 Ansible 或 Puppet 为您提供漏洞补救。
OpenSCAP 将要求您在 Linux 桌面上安装 OpenSCAP workbench 工具,以允许您配置配置文件。
Tip
在开始编写自动化代码之前,检查 OpenSCAP 是否能为您做到这一点。
漏洞扫描
密切关注您的财产,确保没有漏洞,这对于确保您不会有任何令人讨厌的惊喜等着您是至关重要的。
Linux 扫描工具
open vas!open vas!open vas
Nessus 是许多系统管理员在职业生涯中可能听说过的工具。在 Nessus 成为 Tenable 的 close sourced 之前,OpenVAS 是 Nessus 的一个分支。OpenVAS(开放漏洞评估系统)是名为 Greenbone Vulnerability Manager 的大型工具集的扫描器组件。
OpenVAS 还从具有良好历史记录并每天更新的实时提要中获取检测漏洞所需的测试。
OpenSCAP
OpenSCAP 是另一个非常好的漏洞扫描工具,它不仅仅是前面讨论过的扫描工具。OpenSCAP 能够使用多种配置文件,并且可以根据您组织的要求进行完全定制以进行扫描。
我在呼唤
如果你需要一个开源的反病毒软件,ClamAV 可以帮助你检测病毒、木马和许多其他类型的恶意软件。ClamAV 可用于扫描个人电子邮件或文件中的任何恶意内容。ClamAV 也可以作为服务器端的扫描器。
“付费”ClamAV 产品会自动定期更新其数据库,以便能够检测最近的威胁。社区产品需要进一步配置 cron 作业。
集装箱图像扫描工具
今天运行 Linux 资产需要管理的不仅仅是标准的 Linux 系统。与标准 Linux 系统一样,需要对容器和构建它们的映像进行漏洞扫描。
海港
从技术上讲,是一个容器映像库。Harbor 是一个开源项目,它提供了对其容器注册表的基于角色的访问,并具有扫描图像寻找漏洞的能力。VMware 采用 Harbor 作为其 Tanzu Kubernetes 平台的容器注册中心。
基于角色的访问
Harbor 通过策略和基于角色的访问控制来保护工件,确保图像经过扫描并且没有漏洞。
特里维
Harbor 在 2.2 版本之前使用 Clair 作为其漏洞扫描器,但此后开始使用 Trivy。Harbor 还可以连接到多个漏洞扫描器。通过将 Harbor 连接到多台扫描仪,您可以扩大防御漏洞的范围。
单个或多个图像
可以启动 Harbor 来扫描港口环境中的特定图像或所有图像。还可以将策略设置为以特定的时间间隔自动扫描所有图像。
jfrog 射线
JFrog Xray 是 JFrog 提供的漏洞扫描工具。Xray 与 Artifactory 本机集成,用于扫描漏洞和软件许可证问题。x 射线能够扫描所有支持的包类型,从二进制文件到容器映像。
深度扫描
深度扫描允许 Xray 在发布用于实时部署之前,通过 Artifactory 中的包或工件的依赖性递归扫描任何威胁。
克莱尔
Clair(来自法语术语,意思是 clear)是一个开源项目,它为容器映像和应用程序容器提供静态安全性和漏洞扫描。
支持的图像
Clair 目前支持的可以扫描漏洞的映像包括本书中讨论的所有主要企业发行版。它们如下:
-
人的本质
-
一种自由操作系统
-
红帽企业版
-
注意
-
神谕
Clair 还支持目前在不同环境中使用的以下图像:
-
阿尔卑斯山的
-
linux
-
VMware 光子
-
计算机编程语言
企业版
Clair 目前是 Red Hat Quay(读作“kway”而不是“key”)产品中使用的漏洞扫描工具。Clair 为 Red Hat 支持的容器注册表提供了一个企业级漏洞扫描工具。
连续扫描
Clair 扫描推送到 Quay 的每张图像,并持续扫描图像,以提供您的集装箱中已知漏洞的实时视图。
仪表盘
Clair 也有一个详细的仪表板,显示码头内存储的集装箱图像的状态。
管道
在 DevSecOps 方法中,Clair API 可以在 Jenkins 或 Tekton 等管道工具中使用,以扫描烘焙阶段创建的图像。
集装箱平台扫描工具
Kubernetes 的 Red Hat 高级集群安全性(StackRox)
红帽最近的一次收购是将 StackRox 纳入红帽的投资组合。StackRox 目前是 Red Hat ACS 产品的上游项目,但仍有一个社区版本可用于不受支持的平台。
Red Hat 的企业版 StackRox 提供了以下特性。
漏洞扫描
在 Kubernetes 或 OpenShift 平台内运行的容器中发现并修复漏洞的能力。
合规扫描
在信息仪表板的支持下,Red Hat ACS 可以扫描集装箱和图像,以确保它们符合 CIS、PCI 或 NIST 等标准的合规性要求。
网络分段
能够执行网络策略,并对进出 Kubernetes 或 OpenShift 环境的允许网络流量进行更严格的分段。
风险预测
从 Kubernetes 或 OpenShift 内的部署中检测到的所有风险都可以在优先列表中查看,以便进行补救。
结构管理
不仅用于管理 Kubernetes 或 OpenShift 中容器工作负载的安全性和漏洞。Red Hat ACS 还可以通过配置管理强化集群组件。
检测和响应
通过结合使用规则、允许列表和基线,Red Hat ACS 能够识别可疑活动并采取措施防止攻击。
法尔科
由 Sysdig 创建的 Falco 是另一个针对 Kubernetes 和 OpenShift 类型环境的开源威胁检测解决方案。Falco 可以检测应用程序中的任何意外行为,并在运行时向您发出威胁警报。
法尔科有以下特点。
灵活的规则引擎
通过使用类似于 tcpdump 的语法,Falco 可以使用 libscap 和 libsinsp 库构建规则,从 Kubernetes/OpenShift API 服务器或容器运行时环境中提取数据。然后,可以从特定名称空间或容器映像上的元数据创建规则。
即时警报
通过即时警报降低财产风险,从而更快地修复漏洞。
当前检测规则
基于最新 CVE 或已知漏洞的最新检测规则。一旦安全平台发现漏洞,您也会发现。
水上安全
Aqua Security 旨在保护使用云原生容器构建并部署到 Kubernetes 或 OpenShift 等混合云基础架构中的应用程序。
Aqua Security 具有以下特性。
开发者指南
Aqua Security 通过确保容器映像中没有任何已知的漏洞,指导开发人员构建安全、干净的容器映像。Aqua Security 甚至检查正在开发的容器图像没有任何已知的密码或秘密,也没有任何可能使这些图像易受攻击的安全威胁。
信息仪表板
Aqua Security 有一个清晰而有用的控制面板,提供关于所管理平台的实时信息,以及发现的所有问题。如果发现任何漏洞,Aqua Security 会将问题报告给开发人员,并提供修复易受攻击的映像所需的建议。
摘要
在本章中,向您介绍了以下内容:
-
应该使用并且永远不要禁用的标准 Linux 安全工具
-
保护新系统时应至少使用的 Linux 配置
-
理解什么是 DevSecOps,以及这种新的实践需要如何被组织中的每个人所接受
-
系统合规性和 Linux 强化
-
可用于强化 Linux 系统以满足合规性要求的指南
-
漏洞扫描工具
十、维护任务和计划
任何 Linux 系统管理员都会熟悉 Linux 资产所需要的可怕的维护。在本章中,我们将讨论在管理 Linux 资产时应该做的各种维护工作。我们将了解应该完成哪些实际维护工作,应该在何时运行维护作业,以及如何计划维护以使停机时间最少。
本章还将简要介绍如何同步维护任务和官僚任务,以减少日常维护有时会带来的总体痛苦。最后,我们将讨论如何使用自动化来改善所有相关人员的整体维护体验。
应该做哪些保养
在 Linux 服务器上应该进行一些检查。有些可能不需要在每个维护周期进行,但有些需要尽可能经常进行。有时你甚至需要运行紧急维护。
Note
为了确定维护是否至关重要,请注意您对潜在问题迹象的监控。这方面的例子可能是磁盘即将被填满。
修补
维护的首要原因是打补丁和系统更新。这一过程的重要性怎么强调都不为过,也绝不能忽视。修补不仅包含软件包更新和修复,还提供漏洞补救。
脚手架
在确认当前一轮更新不会破坏任何东西之前,修补您的生产/现场或面向客户的环境从来都不是一个好主意。
这就是为什么应始终采用分阶段修补方法的原因。确定修补环境的顺序,并分阶段进行修补。
图 10-1 是我过去经常使用的配线订单示例。
图 10-1
修补顺序
沙箱
从沙盒类型的环境开始,至少有一个系统运行与您的生产环境相似或接近相同的应用程序。这种环境不应该面向用户,也不需要变更控制批准。整个环境应该是一次性的和自动化的。沙盒是您的环境,用来证明配置不会在其他环境中引起问题。
自动化测试
如果可能,利用自动化测试来证明更新或补丁配置没有破坏测试应用程序的功能。有许多开源和专有的选项可用于自动化应用程序测试。与您组织的开发人员交流,或者联系为您提供应用程序的人员。他们很可能会建议你应该使用什么。
这里有一些选项,你也可以看看,可能会有所帮助:
-
硒
-
加泰罗尼亚工作室
-
Appium(用于移动应用程序)
-
机器人学
自动修补
如果您的修补过程计划得很好,并且平台测试可以自动化,那么就没有什么可以阻止您自动化实际的修补工作。
利用自动化工具,如 Ansible Tower 或 Jenkins 或任何允许您运行阶段或工作流的工具。这样,您可以分阶段运行以下内容:
-
预检
-
确认故障转移已经发生
-
修补操作系统文件
-
重新启动
-
自动化测试
反转
如果检测到问题,管道或工作流工具也可以应用回滚,确保当维护窗口关闭时,不会留下任何有问题的状态。自动化是伟大的,但是内置同样多的风险管理将使您不必解释为什么环境被您的自动化破坏。
Hint
您希望确保尽可能多地降低风险,以确保您的自动化不会因系统停机而受到指责。这让你的生活变得更容易,应该避免反对者。
文件系统
如果没有很好地维护,随着时间的推移,有一个领域可能会增长并引起关注,那就是您的文件系统。文件系统不仅存储日志,还存储用户留在主目录中的文件。在文件系统成为问题之前关注它们对于避免可预防的停机至关重要。
清除
在系统维护期间,浏览以下不同的文件系统并检查是否有不再需要的文件绝对是值得的。建议删除这些文件和任何临时文件。
检查错误
一旦您检查了未使用的文件并尽可能地清除了这些文件,那么运行文件系统健康检查就非常值得了。这将有助于识别任何潜在的问题,以免它们成为下一步的问题。
文件系统检查命令
表 10-1 中的命令在运行文件系统维护或通常希望解决磁盘问题时非常有用。
表 10-1
基本文件系统检查命令
|Linux 命令
|
描述
|
| — | — |
| du -k /var/log | sort -n | tail -10
| 检查目录中最大的十个文件 |
| find . -type f -size +100M -ls
| 在当前目录中查找任何大于 100MB 的文件 |
| find /var/log -mtime +90 -ls -exec rm {} \;
| 找到任何超过 90 天的文件并删除它们 |
| tar -zcvf var_log.
date +%Y%m%d.tar.gz /var/log/*.log
| 在/var/log 目录中创建一个包含所有日志文件的 tar 文件 |
防火墙
防火墙检查只是为了确保没有意想不到的新规则进入您的 Linux 系统。从技术上讲,这些应该由配置管理工具来管理,但是在没有运行的 SaltStack 或 Puppet 的情况下,检查防火墙是一项快速而简单的任务。在维护窗口期间这样做只是意味着您可以删除任何不需要的更改,前提是您被任何更改控制所覆盖。
Important
设计平台的内部架构师应该始终推荐防火墙规则。如果出现了任何没有意义的规则,请参考原始设计来确认它们应该存在。
备份
这个真的不用说了。对于任何无法通过代码重建的系统,都应该在可接受的时间范围内进行备份。虚拟机可以完整备份,但物理系统需要根据服务器的功能备份特定的目录。
在维护窗口期间,仔细检查所有备份是否都已运行,以及最近的备份是否到位。
Important
在修补系统或对系统进行任何可能会使您处于停机状态的操作之前,请确保您有一个可从中恢复的最新备份。
您的房产应该多久进行一次维护取决于几个因素:
-
您希望多久修补一次您的环境?
-
您是否遇到过磁盘已满或磁盘损坏的问题?
-
您的平台上是否出现了意想不到的配置?
前面两点表明你的房产有比维护更大的问题;在试图解决症状之前,建议先解决这些问题。
尽可能经常
应该定期执行的明显任务是打补丁。修补周期取决于组织的策略,可以是每 7 天或每 90 天。在我看来,90 天太长了,应该缩短到至少 30 天,但这也太长了一点。
如果让您来做决定,我会建议尽可能频繁地打补丁。应使用自动化,并通过定期维护帮助减少人为因素。通过运行非常定期的维护和修补程序,您可以降低新发现的漏洞可能带来的任何风险。
没有测试就没有实时修补
定期修补还允许您使用分阶段的方法进行修补,从而减少未经测试的配置或更新可能出现的问题。
结构
通过为每个环境建立一个定期维护窗口,您可以计划和组织如何应用和测试更新。这样做,您就大大降低了您的实际环境中出现问题的可能性,包括错误和漏洞。
应该如何进行维护
很简单,自动化维护是当今的发展方向。在我们维护和构建平台的过程中,需要减少人为因素。这是你能真正扩展的唯一方法。让一个人或一个团队来运行维护是疯狂的,更不用说维护是否会像应该做的那样定期进行。
自动化
我相信我提到自动化的次数已经足够多了,以至于你们已经厌倦了这个术语,我也相当有信心你们大多数人现在已经在自动化了。
显而易见,自动化维护和自动化构建过程一样重要。以下是您应该自动化的项目:
-
备份
-
修补
-
磁盘清理
-
磁盘检查
-
防火墙和 SELinux 配置
-
软件删除
前面的几项应该由配置管理工具来管理,但是如果您没有使用任何工具,那么您的维护自动化应该会处理它们。
您的自动化也应该按照类似于以下的顺序运行:
-
检查并确认最近进行了备份。
-
应用任何系统更新。
-
运行自动化测试以确认更新没有破坏任何东西。
-
磁盘清理
-
配置检查。
-
如果测试失败,回滚更新。
-
更新监控或生成报告以反映状态。
零停机环境
如果您的环境被认为是关键的,并且能够承受零停机时间,那么您将需要在蓝/绿风格的部署中运行多个数据中心或每个站点的多个环境。
蓝色/绿色
这种方法包括将流量转换为蓝色或绿色,然后修补非实时环境。
如果您愿意,蓝/绿方法确实让您能够直接更新到您的实时环境中,因为从技术上讲,您并没有更新“实时”端。如果您做了所有的尽职调查,并确保您修补的环境在切换回来之前 100%运行,您应该不会遇到宕机。
一旦您完成了一侧的维护,您可以将相同的维护应用到第二侧。因为你已经证明了没有问题,你应该完全可以继续你的第二个网站。
我个人仍然建议采取分阶段的方法,但是如果你时间紧迫,你至少可以切换回第二个环境。
故障切换
运行多个数据中心是减少单点故障的另一种常用方法。将实时流量转移到第二个数据中心将允许在实时流量不停机的情况下进行维护。
在回切到主数据中心和修补辅助站点之前,应该应用相同的维护原则。
维护计划
执行和计划一样好。对于任何维护计划,都有一些重要的事情需要考虑。
同意维护窗口
为每个环境的维护找到一个固定的时间段。自动化官僚主义的繁文缛节,以确保维护可以在这些定期运行。通过为您的组织寻找和规划一个已知的时间段,您将始终能够应用更新和更改,而无需每次都争论原因。
这并不意味着您必须每次都运行维护,您只需要在需要时自由地进行维护。
如果你已经自动化了这个过程,那就更好了。然后,您的环境可以不断保持最新状态并尽可能平稳地运行,减少不断修复问题的需要,让您有更多时间专注于更令人兴奋的事情。
一口大小的块
如果你有大量的维护工作要做,并且还没有自动化这个过程,把你的维护工作分成小块。宁可运行多个小维护窗口,也不要运行一个大窗口。
Remember
疲惫的眼睛对任何人都没有帮助。
评估的艺术
在计算完成一项任务所需的时间时要小心。宁可高估早完成,也不要低估,给自己压力。向其他 Linux 系统管理员寻求帮助,在计划时估算时间。
将流程和任务一起自动化
自动化不仅仅是技术任务的实现。今天,在你的组织中自动化“繁文缛节”过程也是可能的。
在系统维护的情况下,这个功能可以很好地与任务自动化结合起来。所有批准都可以自动化,并输入到您的技术自动化平台,以便在维护窗口到来时继续进行。你不仅不必再做手工的技术实现,还可以避免官僚主义的工作。
工序自动化
现在有一些不同的产品和项目可以帮助您自动化流程,但是值得一提的是 Red Hat Process Automation Manager,或者 PAM。
红帽子帕姆
Red Hat PAM 提供了自动化业务流程和决策的工具。通过使用高级业务规则和流程引擎,以及复杂的事件处理和案例管理,Red Hat PAM 可以帮助解决复杂的计划和调度问题。PAM 利用 Drools 的全部功能,Drools 是一个强大的、广泛使用的开源规则引擎。通过使用内置的规划求解工具,PAM 甚至可以帮助解决复杂的优化问题。
像大多数其他 Red Hat 产品一样,Red Hat PAM 的上游项目是 jBPM 项目,这是一个完全开源的产品,可以在社区支持下使用。
Warning
Red Hat PAM 是您需要用来开发流程任务的工具,就像您在自动化技术任务时使用 Ansible 一样。
摘要
在本章中,向您介绍了以下内容:
-
Linux 系统需要做哪些维护
-
何时应该运行 Linux 维护
-
零停机运行维护的方法
-
如何规划 Linux 维护
-
如何将维护流程和技术任务一起自动化
十一、故障排除
如果您不了解正确的方法,故障排除可能是一项难以掌握的技能。仅仅挖掘日志或配置文件可能有助于解决简单的问题,但是理解如何找到问题的根本原因才是真正的技能所在。在这一章中,我们将看看应该如何看待一个问题,应该如何分析这个问题,最后你应该如何根据你所看到的信息采取行动。在猜测之前花时间去理解对更快更有效地解决你的问题是至关重要的。
一旦我们讨论了应该如何处理问题,我们将讨论在社区中提问时应该使用的适当礼仪。第一步是学会不要让别人替你做工作,或者至少用一种你似乎已经尝试过的方式来提出你的问题。在这一章中,我们将探讨寻求帮助的最佳方式。
最后,我们将讨论您应该尽量避免的不太好的故障排除方法。
观察,分析,然后行动
成为一名有效的故障排除者的艺术是成为一名调查者。跟着线索,问正确的问题。注意每一个小细节,最重要的是理解为什么问题会首先出现。太多时候,绷带被用于症状,而根本问题并没有得到解决。解决了根本原因,你就可以省去以后所有的痛苦。
理解问题
为了完全理解如何修复一个问题,你需要理解问题的影响是什么;这很可能会给你第一个线索,告诉你从哪里开始找。
为了有效地解决问题,你需要了解你正在诊断的是什么,如果你不知道它是如何工作的,猜测是没有意义的。你将只能得到部分答案,并有可能浪费时间在错误的地方寻找答案。
例如,如果你有一个网络问题,但不知道如何跟踪网络流量,你最好找一个知道如何解决这个问题的人。边走边学是我们获取经验的方式,所以不要害怕寻求帮助。适当的做就好;我们很快会谈到这一点。
知道从哪里开始
知道从哪里开始是让你彻底了解问题的一半。从顶部开始听起来像是老生常谈,但这就是你如何通过证据沿着面包屑工作,最终将你带到根本原因。
开始时问正确的问题会让你知道从哪里开始挖掘。当问题被描述为“它坏了”或“它坏了”时,这意味着你的问题需要从简单开始,然后随着你的深入变得更加复杂。请记住,您的问题要基于与您一起工作的人的知识水平,并且要有耐心。
开始时要问的标准问题
当您初次遇到某个问题时,您需要从报告该问题的人的角度来理解该问题。为此,你应该问我们在 IT 学校都学过的标准问题。类似于下面的问题:
-
你能告诉我发生了什么吗?
-
问题是可重复的还是间歇性的?
-
有什么变化吗?
Note
问自己这些问题没有错。如果有的话,它可能会让你加深对这个问题的理解。
解释问题
当一个问题很复杂时,它需要深入思考、质疑和理解。只有通过解释,它才变得更加清晰。通过多次解释和提问,你增加了对问题的了解,直到得到答案。
这里有一些技巧可以用来解释你的问题。
向自己解释
几十年来我们已经知道,向自己解释一个问题可以大大增加我们解决它的机会。通过向自己解释这个问题,你获得了关于这个问题的新知识,你问自己问题,并且挑战自己对这个问题的理解。如果有帮助的话,大声对自己说,继续对自己谈论这个问题。不要沉默不语,如果有必要的话,找一个安静的房间,彻底解决这个问题。
橡皮鸭
如果在向自己解释完问题后,你仍然没有什么有形的东西,那就抓住一个无生命的物体(橡皮鸭),向它解释你的问题。只是第二次解释的过程可能会有帮助。
另一个人
如果橡皮鸭选项失败了,试着向另一个人解释你的问题;他们甚至不必是技术性的。事实上,如果他们不是,可能会更好。这可以让你简化你的解释,让他们理解,并可能在这个过程中帮助你发现一些你可能忽略的东西,因为它太简单了。
使用工具
解释时使用白板或碎纸片也能让你把想法和想法从脑子里赶出去。向自己重读解释可能会更加清晰。
分解问题
复杂的问题会涉及许多不同的活动部件。一点一点地理解这些部分不仅会让你对问题更加清晰,还会让你开始消除可能的原因。
将问题分解成各个部分,开始向自己解释这些部分的作用,询问问题是否存在于每个部分,然后排除可能不是问题的部分。
使用白板或一张纸是一种很好的方法,可以将您的问题可视化到不同的部分。
洋葱,它们有层次
当你分解问题时,记得考虑所有相关的层面。如果您遇到应用程序问题,请查看从应用程序到物理硬件的所有内容。通过排除所有的不可能,你只剩下最有可能的。
五个为什么
虽然不是每个人都喜欢自言自语或涉及无生命的物体,但有另一种类似的方法可以用来解决复杂的问题:一种称为五个“为什么”的技术
在这种方法中,故障诊断人员通过五个问题来解释为什么会出现问题。
例子
如果我们假设一个场景,在晚上的维护之后,你组织的内部内部网无法加载,那么可以问一下图 11-1 中所示的“为什么”。
图 11-1
尝试确定潜在问题时“为什么”应遵循的流程示例
内部网坏了。为什么呢?应用了更新,系统重新启动。为什么呢?web 服务器没有监听任何端口。为什么呢?启动后 web 服务器服务不会启动。为什么呢?配置文件中有语法错误。为什么呢?最后一个为什么会让你找到根本原因。有人更改了 web 服务器配置,但没有测试语法。这种改变并没有通过重启 web 服务来实现,只有在应用了系统更新后重新启动 web 服务器时,真正的问题才显现出来。
在这个例子中,问题归结于发生在内部网 web 服务器上的一个未记录的变更。该更改从未在语法检查中测试过,并且该服务从未重新启动以应用该更改。在服务器更新和重新启动后,web 服务器尝试在启动时启动,但由于语法错误而失败。
基于证据的理论
在对困难或间歇性问题进行故障诊断的过程中,您可能需要找到不同的调查途径。每种途径都需要调查,并需要证据来证明它是确凿的证据,然后才能将修复应用到受影响的实际环境中。
假设构建
图 11-2 所示的工作流程可以通过建立一系列假设来帮助你进行根本原因分析。
图 11-2
建立故障排除假设时应遵循的流程
Tip
在建立你的假设之前,不要太快忽视不可能的事情,除非你 100%确定它不是问题所在。
建立你的理论
一个好的理论应该总是从一个好的假设或有根据的猜测开始。为了检验假设,需要收集关于可疑区域的所有信息。这可能包括配置文件、系统负载、内存使用情况或任何有助于您重现实际环境中遇到的问题的信息。
因果关系
在建立你的假设时,要避免陷入不理解某个组件的因果的陷阱,例如,因为一个新的显卡加载失败而责怪内核版本。即使内核负责设备驱动程序,它仍然需要在内核中编译的硬件驱动程序。
证明你的理论
因为在真实环境中调试和测试从来都不是一个好主意,所以在你可以将任何东西应用到真实环境之前,你的理论需要坚实的证据来支持你的主张。为此,你需要证明你的理论。
重现问题
为了证明你的理论,你首先必须重现这个问题。收集到证据后,您必须尝试复制与真实环境相同的条件,看看您是否会遇到相同的问题。如果你不能重现问题,可能你有错误的理论,或者你没有收集所有的证据。
在测试环境中修复
如果您能够重现该问题,则可以测试您的潜在修复方法,并证明问题已经解决。理想情况下,整个过程应该是可重复的。
补救
最后,通过验证您的理论和准备好的解决方案,可以在几乎没有风险的情况下修复实际环境。
请求帮助
在我职业生涯的早期,我被告知要经常寻求帮助,不要浪费超过解决问题所需的时间。如果我被卡住了,我不应该在问之前“敲打我的头”太久。毕竟,我们都还在学习;我们在一个不断发展变化的行业中工作。坐在你旁边或在互联网上的某个人可能已经经历了你遇到的同样的问题,并且可能有你可能正在挣扎的答案。
在寻求帮助之前应该做什么
当你寻求帮助时,你是在要求别人放弃一些时间来帮助你解决你的问题。帮助你的人必须花精力去理解你的问题;他们需要想出一个他们过去可能用过的可能的解决方案,然后试着用你能理解的方式向你解释。
为此,作为请求者,您至少应该在提出问题之前完成以下工作:
-
尝试修复问题,但失败了
-
阅读软件或硬件供应商提供的文档
-
在互联网上搜索其他人已经尝试过的例子,并检查没有人已经问过你想要帮助的问题
培养
如果你足够幸运,可以接触到培训材料,检查一下你在练习中可能学到的东西是否有帮助。
如果你从未接受过任何培训,可以和你公司的经理谈谈,让你参加合适的培训课程。如果做不到这一点,你也可以利用大量的在线资源来学习。
如何寻求帮助
以下是你在寻求帮助时需要考虑的一些非常重要的要点。
适当的语法
尽可能使用正确的语法和拼写。如果英语不是你的第一语言,那么尽你所能,用类似这样的话开始你的问题:
“很抱歉我的英语不好,希望我的问题有意义。”
尽量避免使用俚语,尽可能使用正确的单词拼写。记住你是在寻求帮助,确保你的问题尽可能清楚。
拼写
使用任何可用的工具对你的问题进行拼写检查。谷歌文档有不错的拼写检查功能(我希望如此,因为这本书是用它写的),而且是免费的。
将您的问题写或复制到一个新文档中,并检查语法和拼写错误。
如何表达你的问题
现在,随着正确拼写和语法的使用,你需要理解你的问题应该如何措辞的重要性。
简单地问“有人知道为什么我的显卡不能在我的 Linux 桌面上工作吗?”不够或者写得不好。
问一个让人们立即向你询问更多细节的问题不会给你想要的答案或任何答案。
将你的问题改为包含以下信息,你会得到更好的回答:
-
陈述你尝试过的。
-
给出所有组件的详细信息,比如显卡的品牌和型号。告诉读者你用的是什么 Linux 发行版。
-
说明您已经阅读了文档并浏览了其他示例。
-
在你的问题主体中非常具体地说明你的问题,并在上面用一行字概括你的问题。
一个更好的问题
镭龙 RX 5700xt 驱动程序不支持 Fedora 34
我正在尝试在新安装的 Fedora 34 中安装镭龙 RX 5700XT 显卡。在阅读了 AMD 网站上的官方文档并查看了 install 命令的帮助后,我仍然无法找到解决方案。
我已经尝试运行命令
./amdgpu-install-pro --opencl=pro,legacy
和 ./amdgpu-install-pro --opencl=rocr,legacy
但是两者都给了我错误。
“找不到设备”
下面是我的日志文件的输出。
“日志文件条目”
任何帮助我都会非常感激,或者你可能有的任何我可能错过的文件也会非常有帮助。
Tip
不要急着提问;花点时间以清晰、平和的方式问问题。人们会对花时间和精力正确提问的人提出的问题做出回应。
在哪里提问
如何提问对于获得积极的回应至关重要,但在哪里问措辞正确的问题同样重要。
正确区域
人们真的不喜欢被问到与你提问领域无关的问题。在提问之前,请确保您选择了正确的论坛或聊天室,甚至支持电子邮件。
一般礼貌的回答会把你引向正确的地方,但是没有耐心的人可能会给你一个稍微有点讽刺的回答。所以一定要避免尴尬或至少浪费你的时间。在应该提问的地方提出你的问题。
论坛
如果你对某个特定的产品或项目有问题,检查一下他们是否有你可以提问的论坛。确保首先检查您的问题是否还没有被问过。
GitHub,堆栈溢出
在很多网站上,你可以就你可能遇到的任何问题提出技术问题。Stack Overflow 是一个我能找到答案的常见网站,但是像 GitHub 这样的地方也能提供一些很好的见解。
支持案例
如果您的问题与您或您的组织付费订购的企业产品有关,请向他们的帮助台提出支持案例。这毕竟是你花钱买的东西。
但是,一定要清楚你的问题是什么。尽可能附加日志文件和潜在的诊断输出。只需添加所有相关文件,有时就可以更快地解决问题。
排除故障时要避免的事情
故障排除通常不是我们为了好玩而做的事情;它通常有时间压力,要求你尽快解决问题。
为了避免浪费时间,有几件事你应该尽量避免。
现场调试
不要在真实环境中调试;谁要是说现场调试还可以,那就是如履薄冰。只需一个语法错误或一个配置文件留在调试模式中,就会导致停机。
构建测试环境和非生产环境是有原因的。用它们来找到根本原因,而不是你的生活环境。
相关性与因果关系
当你寻找问题的根本原因时,运用逻辑思维关注问题可能出在哪里。将问题从可能有责任的组件中分解出来,避免关注依赖于可能有故障的组件的组件。基本上,避免浪费时间在可能是根本原因的受害者而不是原因的地方。
在服务没有启动的情况下,如果您没有首先检查应用程序配置,就不要浪费时间查看服务文件。我并不是说不要检查服务文件的语法问题或潜在的变化,只是不要区分它的优先级。
做一只孤独的狼
不要默默忍受;寻求帮助,两人一组。两对眼睛总会比一对好。两个大脑思考问题的方式不同,会从不同的角度处理问题。不要花几个小时独自战斗。
猜测和撒谎
这确实与团队故障排除有关。如果你对已经发生的事情负有责任,并且你已经请求帮助你摆脱困境,那么 100%诚实,不要猜测你可能在哪里犯了错误。
承认一个错误通常只会被当作“一个错误”对问题撒谎,由于缺乏诚实而导致延误,很可能对你没有好结果。拥抱你的错误,并从中吸取教训。
鬼
不是每个人都理解“红鲱鱼”这个词,但在英国我们用这个词来指代不存在的东西。一个幻影。避免寻找不太可能成为你问题根源的东西。当你寻找根本原因时,要坚持运用逻辑思维。
所有的小事
不要认为所有的大问题都有大的原因。不要忘记检查简单的事情,如域名系统或磁盘已满?
通常,我们最意想不到的事情会导致最大的问题;坚持从基础做起,然后从基础做起。
记录你已经尝试过的事情
阿尔伯特·爱因斯坦说过:“疯狂的定义是重复做同样的事情,却期待不同的结果。”说到故障排除,没有什么比这更不真实的了。如果你有健忘的天性,记录下你检查的地方和结果。这样你就会避免重复自己,浪费时间。
测量两次,切割一次
这句老话同样适用于解决方案。为了让事情立即工作而应用肮脏的变通方法,但随后不得不在短时间内修复相同的问题是徒劳的。找到根本原因并应用永久修复应该是你的首要任务。
如果您的实际环境出现故障,您最好在灾难恢复站点或辅助站点中运行。如果不是这样,那么我会担心比停机更大的问题。
什么更有意义?
修复问题以便它不会再次中断,还是应用会导致另一次中断的解决方法?
争论用更长的时间来修复潜在的问题比解释为什么现场环境再次下降要好得多。
别忘了你的回顾展
故障排除的最终目的是找到问题的根源。第二个目标应该是永远不要让它再次发生。为此,与所有相关人员进行讨论并计划如何避免该问题至关重要。
记录问题以及问题是如何解决的。如果问题不知何故再次发生,有一些参考资料可以节省时间。
摘要
在本章中,我们探讨了以下有关故障排除的内容:
-
通过向自己和“他人”解释,学会理解你的问题
-
把你的问题分解成最小的部分,然后从那里着手。
-
五个为什么以及简单地问为什么一个东西坏了可以帮助你找到罪魁祸首。
-
在将任何解决方案应用到您的生活环境之前,如何建立一个关于可能导致您的问题的原因的理论,并证明您的理论。
-
寻求帮助的正确方法,包括在寻求帮助之前应该做些什么。
-
排除故障时要避免的事情。
十二、高级管理
《21 世纪 20 年代的 Linux 系统管理》的最后一章将探讨作为 Linux 系统管理员的你如何更深入地挖掘 Linux 操作系统,以找到你需要的信息。
本章将从研究系统分析开始,并帮助你理解如何从你的 Linux 系统中获得更多的信息,而不必花时间去做这些。我们将讨论什么样的工具可以用来提取和破译系统信息,让你更快地得到答案。
当系统分析工具和技术不能给你所需要的所有信息时,就需要使用额外的工具来获得更多的信息。我们将在本章的剩余部分探讨如何从 Linux 操作系统中提取最后一点信息。
系统分析
作为一名 Linux 系统管理员,您会花时间查看配置文件和一般的系统健康状况,试图查明用户问题的根源。这个过程通常会很痛苦,而且会花费你不想花的时间。拥有正确的工具有助于深入了解问题,并让您专注于更有趣的事情。
这里有一些快捷的工具,您可以使用它们来获得关于 Linux 系统的信息。
系统管理员的工具
如果您有合适的工具,并且知道如何以对您有意义的方式使用它们,那么维护或运行 Linux 资产会是一项更简单的工作。
Sosreport
对于所有的企业 Linux 系统,“sosreport”用于为支持团队提取信息。Sosreport 是一个基于插件的工具,可以使用不同的参数来导出不同的信息。当出现支持案例时,企业支持团队经常会请求 Sosreport 的输出,每当出现新的支持案例时,它总是值得上传。
Sosreports 是有问题的系统配置和日志的存档。支持团队能够使用 sosreport 更好地了解所遇到的问题,而无需请求不同的配置文件。
可以在不指定任何参数的情况下创建 sosreport,如下所示,但也可以传递附加参数以减少输出或增加提取的内容:
# sosreport
作为一名 Linux 系统管理员,您可能希望使用 sosreports 进行自己的诊断查询。如果您希望从自己的测试系统中调查用户的问题,可以手动提取 Sosreports。
如果您对手动提取 sosreports 不感兴趣,可以使用一些工具来提取和总结报告中的配置。
xsos
一个这样的工具是 xsos,由社区成员开发和维护;xsos 可以接受 sosreport 输入,并创建系统的良好摘要。对于支持人员来说,这比大多数人意识到的要节省更多的时间,因为不需要提取或筛选配置文件来快速浏览。
要运行 xsos 的基本测试,您可以运行以下命令:
# curl -Lo ./xsos bit.ly/xsos-direct; chmod +x ./xsos; ./xsos -ya
前面的命令将只输出运行它的系统的详细信息。如果您想要查看 sosreport 输出,您将需要安装 xsos 工具并将路径传递到您的 sosreport。
基本 xsos 报告将输出以下区域:
-
汇总 dmidecode 输出
-
操作系统详细信息
-
Kdump 配置
-
CPU 详细信息
-
中断和软中断
-
记忆
-
仓库
-
兰斯普奇
-
网络信息包括防火墙
-
内核调整配置
Tip
自动化您的 Linux 系统,定期自动生成这些报告,并将输出上传到中央共享。如果您遇到了重大问题,您可以参考这些 SOS 报告,寻找可能出错的线索。
系统信息
关于您的 Linux 系统的所有设备信息都可以在“/proc”目录中找到。在“/proc”中,有不同的文件,如“meminfo”或“cpuinfo ”,它们将向您显示每个组件的相关信息。例如,“cpuinfo”文件将向您显示与您的 Linux 系统相连的所有 CPU 的所有信息,包括 CPU 标志。
快捷工具
如果对“/proc”文件不感兴趣,表 12-1 中列出的工具也可以用来获得关于您的 Linux 系统的基本信息。熟悉这些工具有助于您在需要快速诊断任何问题时快速访问设备信息。
表 12-1
硬件信息的基本 Linux 系统工具
|Linux 命令
|
描述
|
| — | — |
| lshw
| 将列出系统识别的所有硬件的完整摘要 |
| lscpu
| 所有 CPU 信息的摘要,类似于运行# cat /proc/cpuinfo
|
| lsblk
| 所有连接的存储设备的快速列表 |
| lsusb
| 插入 Linux 系统的所有 USB 设备的列表 |
| lspci
| 列出插入 PCI 插槽的所有 PCI 控制器和设备 |
| lsscsi
| 列出连接到系统的所有 scsi 和 sata 设备 |
更多细节
如果快捷工具中的细节不够,您可以使用表 12-2 中列出的工具来提供更多细节。
表 12-2
了解更多细节的工具
|Linux 命令
|
描述
|
| — | — |
| hdparm
| 打印出存储设备的几何图形等细节 |
| dmidecode
| 可用于提供有关您的系统的更深入的信息。使用"-t “参数,后跟” memory “、” processor “、” system “或” bios ",将为您提供每个参数的更多细节 |
系统跟踪
当你被一个棘手的问题困住时,了解幕后发生的事情有时是必要的。作为 Linux 系统管理员,有一些工具可以帮助您获得这些底层细节。
失去了
“strace”是一个非常有用的工具,可以用来查看进程或正在运行的应用程序的情况 Strace 可以作为命令或应用程序的前缀运行,也可以附加到正在运行的“pid”上
装置
在几乎所有的 Linux 发行版中,Strace 都可以在大多数常见的存储库中找到。对于 Fedora,strace 可以按如下方式安装:
# dnf install strace -y
以下命令将显示运行 free 命令时发生的一切:
# strace free -h
输出到文件
使用 strace 时,一个非常有用的事情是将输出发送到一个文件中;从那里,您可以搜索字符串或值。
要将 strace 命令输出到文件中,您可以运行类似于下面的命令:
# strace -o testfile.txt free -h
然后可以在文本编辑器中查看输出文件,在某些情况下,甚至可以用不同的颜色显示不同的调用,以使解释稍微容易一些。
要找什么
以下是使用 strace 可以找到的一些有用的东西:
-
任何试图打开但不存在或显示潜在权限被拒绝的文件-13 个错误
-
正在写入有权限问题的文件
-
来自通过网络传输的进程或应用程序的网络流量
有用的 Strace 参数
表 12-3 列出了一些可以和 strace 一起使用的有用参数。
表 12-3
Strace 参数
|参数
|
描述
|
| — | — |
| -p
| 允许 strace 连接到正在运行的 pid |
| -c
| 创建为该进程运行的所有不同系统调用的摘要 |
| -t
| 显示每一行运行的时间戳 |
| -e trace=open
| 过滤所有系统调用,只包括打开的调用。其他选项包括全部、写入、信号、缩写、详细、原始和读取 |
| -q -e trace=
| 允许跟踪设置为文件、进程、内存、网络和信号 |
安装
另一个从 Linux 系统中提取信息的好工具是“systemtap”Systemtap 是一种脚本语言,它使用带有“.”的文件。stp”扩展名。Systemtap 可用于诊断基于内核的 Linux 平台的复杂性能或功能问题。
装置
Systemtap 可以手动安装,也可以使用自动安装方法安装。
手动安装
systemtap 需要的基本包是 systemtap 和 systemtap-runtime。在 RHEL 系统上,以下命令将安装您的软件包:
# yum install systemtap systemtap-runtime -y
自动安装
Stap-prep 是一个简单的实用程序,它将计算出 systemtap 的需求并为您安装它们。要使用 stap-prep,需要安装软件包“systemtap-devel”。
一旦安装了 systemtap-devel 包,运行 stap-prep 命令。将安装当前运行的内核所需的文件。
Systemtap 用户
如果您使用的是普通的 Linux 内核模块后端,那么您可以 root 身份运行“stap”。但是,如果您希望允许其他用户创建和运行 systemtap 脚本,则必须创建以下用户和匹配组:
-
stapusr
-
斯塔德夫
“stapdev”和“stapusr”组中的任何用户都可以像拥有 root 权限一样运行 systemtap。“stapusr”中的用户只能启动(使用“staprun”)预编译的探测模块。
“stapusr”组中的用户也可以创建自己的基本无特权 systemtap 脚本。
Systemtap 脚本
在安装了 systemtap 的所有系统上,您都可以访问示例脚本。这些可以在以下位置找到:
/usr/share/systemtap/examples/
运行 Systemtap 脚本
如上所述,systemtap 文件保存在。stp 扩展和使用 stap 命令运行。
要测试 systemtap,请使用提供的示例,如 disktop.stp 示例脚本。该脚本显示了当前哪些进程正在向磁盘写入数据。该脚本可在以下位置找到
/usr/share/systemtap/examples/io/disktop.stp
该脚本的作用是探测内核以获取有关所连接的块设备的信息:
# stap -v /usr/share/systemtap/examples/io/disktop.stp
一旦脚本运行,您将看到脚本探测内核的任何磁盘操作。
要对此进行测试,请在新窗口中运行类似于以下内容的 DD 命令:
# dd if=/dev/zero of=file.txt count=1024 bs=1048576
交叉仪器
通常在实际环境中,不可能安装所有的 systemtap 包来运行探测或测试。因此,只需安装 systemtap-runtime 包就可以创建 systemtap 模块并执行它们。
这将允许一个系统被用作可用于编译 systemtap 仪器模块的编译器。然而,内核版本需要匹配,系统需要相同的架构。要为不同的内核版本构建不同的模块,只需将构建系统重启到不同的内核。
要创建跨工具 iotop 模块,可以运行以下命令:
# stap -p 4 -m iotop /usr/share/systemtap/examples/io/iotop.stp
创建后,这些模块需要由 sysadmin 复制到要在其上执行模块的系统的/lib/modules/uname-r
/ systemtap 中。
系统调谐
Linux 系统管理的另一个重要方面是了解如何针对需要执行的任务调优 Linux 系统。
如果您没有任何供应商的指导,或者如果您是管理 Linux 系统的新手,这个过程可能会很困难。
调整
调整 Linux 系统的过程可能涉及到对内核参数和系统配置的深入理解。但是,有一个非常好的工具叫做“tuned ”,它能够使用不同的概要文件来调整系统。
装置
Tuned 可以通过 yum 简单地安装在 RHEL 系统上,如下所示:
# yum install tuned
Tuned 还需要启用并启动服务:
# systemctl enable tuned
# systemctl start tuned
使用调谐的
Tuned 在安装过程中提供了许多概要文件。要查看当前活动的配置文件,您可以运行以下命令:
# tuned-adm active
要列出所有可用的配置文件,您可以运行命令
# tuned-adm list
最后,要切换到不同的概要文件,您可以运行
# tuned-adm profile <name of profile>
摘要
在本章中,向您介绍了以下内容:
-
Linux 系统分析工具,如 sosreports,以及如何以快速简单的方式阅读它们
-
可用于提取系统信息的标准系统工具
-
系统跟踪工具,如 strace 和 systemtap
-
使用调优的实用程序以简单的方式进行系统调优
第一部分:基础
Laying the Foundation
在深入探讨管理大型或小型 Linux 资产的高级或中级主题之前,非常重要的一点是,我们需要建立必要的基本技能来充分理解这本书。这是第一部分的主要目的。
第二部分:强化核心技能
Strengthening Core Skills
既然第一部分已经完成,并且表达了作为 Linux 系统管理员应该达到的水平,那么第二部分将关注在您可能还没有接触过的领域中构建新的技能。
第三部分:练习和保持
Day Two Practices and Keeping the Lights On
在第二部分中,我们讨论了如何通过探索您可以或者应该使用什么工具来改进您正在做的事情。这些最初的章节是以这样一种方式写的,它让你的头脑能够用更少的资源做更多的事情。我们谈到了管理工具、自动化和集装箱化。
这一部分的目标是了解如何继续保持正常运行,应该考虑使用什么工具,以及应该如何尽可能保持环境的安全性,同时又足够灵活,不会限制创新。
第四部分:观察,分析,然后行动
See, Analyze, Then Act
排除故障和寻求帮助可能是一个优秀的 Linux 系统管理员应该具备的最重要的技能。我们中的大多数人都是通过反复试验来学习这些技能的,或者希望通过别人的经验来学习,比如我的书。接下来的章节将向你展示如何处理和解决难题。