实践部分

Day3

介绍

在Google公司上班的第三天，凤凰计划遭遇了灾难！你赶到办公室，发现Sundar Pichai和开发团队正处于危机之中。昨天你协助开发的应用程序在首次重大测试阶段就出现了严重错误。

紧急警报充斥着监控系统，用户报告应用程序故障，部署流程彻底停滞。莎拉绝望地转向你——高级运维工程师生病请假了，而项目截止日期迫在眉睫。

“我们需要我们最优秀的调查员来处理这件事，”莎拉说着，把事件报告递给你。“你整理文件时条理清晰的方法正是我们需要的。现在我们需要用同样的方法解开这个谜团。”

你的任务是深入分析“凤凰计划”服务器，分析日志和配置文件，找出故障的根本原因。你将使用高级 Linux 命令行工具，将线索拼凑起来，恢复团队辛辛苦苦构建的应用程序的稳定性。“凤凰计划”的未来——甚至可能包括你在 TechNova 的职业生涯——都取决于你的侦查能力！

查看应用程序日志文件内容

作为调查员，你的第一步是检查“凤凰计划”的应用程序日志文件。该应用程序会将日志写入指定位置~/project/logs/app.log。大量的日志信息可能会让你应接不暇，因此你需要迅速找到关键的错误信息，以便了解你昨天参与组织的系统究竟出了什么问题。

任务
筛选~/project/logs/app.log文件，查找所有包含单词“.”的行ERROR。
将筛选后的行保存到名为“.”的新文件中~/project/error_report.txt。
要求
您必须使用命令行工具来搜索文件。
您的搜索输入文件为~/project/logs/app.log：
输出结果必须保存到目录_{/project/error_report.txt中名为“file”的文件中}/project。
输出文件应该只包含包含单词“.”的行ERROR。
提示
该grep命令非常适合在文本文件中搜索模式。
要将命令的输出保存到文件中，可以使用>重定向运算符。如果文件不存在，则会创建该文件；如果文件已存在，则会覆盖该文件。
示例
成功过滤日志文件后，您的~/project/error_report.txt文件中应该只包含错误行：

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).

该文件应恰好包含 2 行，均以时间戳开头，并包含单词“ERROR”。

调查系统启动信息

应用程序错误可能是更深层次的硬件或内核级问题的征兆。查找此类问题的一个好方法是检查内核环形缓冲区，其中包含来自系统启动过程和驱动程序操作的消息。

任务
检查系统内核消息中是否有与fail或相关的行error。
将这些发现保存到名为“.”的文件中~/project/boot_issues.txt。
要求
您必须使用该dmesg命令来查看内核消息。
您的搜索应该fail不error区分大小写。
结果必须保存到名为 .的文件中~/project/boot_issues.txt。
注意：您可能需要管理员权限（sudo）才能访问内核消息。
提示
该dmesg命令显示内核消息。您可以将其输出通过管道传递给另一个命令进行过滤。
管道运算符|将一个命令的输出发送到另一个命令的输入。
该grep命令的-i选项使搜索不区分大小写。
要一次搜索多个模式（例如failOR error），您可以使用grep -E ‘pattern1|pattern2’。
注意：如果遇到“操作不允许”错误，请尝试sudo使用必要的权限运行该命令。
示例
成功过滤内核消息后，您的~/project/boot_issues.txt文件应该包含相关的系统消息：

$ cat ~/project/boot_issues.txt
[    0.330755] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    1.026520] RAS: Correctable Errors collector initialized.
[   28.260800] kernel: [   10.123456] my-driver: probe of 0000:00:1f.0 failed with error -2

该文件应包含内核消息，其中包含“fail”或“error”（不区分大小写）之类的词语，以显示系统启动期间可能存在的硬件或驱动程序问题。

检查 Web 服务器配置文件
未发现关键硬件问题。问题可能出在 Web 服务器配置上。我们来检查一下 Nginx 配置文件，看看它的配置情况。有时，配置错误（例如工作进程数过少）会导致性能瓶颈，并在高负载下导致应用程序崩溃。

任务
在以下位置搜索 Web 服务器配置文件~/project/config/nginx.conf：
找到包含该指令的行worker_processes。
将此行添加~/project/error_report.txt到您在第一步中创建的文件中。
要求
输入文件为~/project/config/nginx.conf：
你必须将结果追加~/project/error_report.txt到目标位置，而不是覆盖它。
提示
你可以grep再次使用它来完成这项任务。
要将输出追加到文件而不是覆盖文件，请使用该>>运算符。
示例
将 worker_processes 行添加到现有错误报告后，该~/project/error_report.txt文件现在应该同时包含原始错误行和新的配置行：

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).
worker_processes 4;

该文件总共应包含 3 行：2 行原始错误信息，加上 1 行包含“worker_processes 4;”的新行。

比较暂存环境和生产环境的配置文件

生产环境中常见的问题之一是测试环境和生产环境之间的差异。某个功能在测试环境中可能运行完美，但在生产环境中却会因为细微的配置差异而失败。让我们比较一下两个环境中应用程序的配置文件，找出其中的差异。

任务
将测试环境配置文件_{/project/config/staging/app.conf与生产环境配置文件进行比较}/project/config/production/app.conf。
将差异保存到名为“.”的新文件中~/project/config_diff.txt。
要求
你必须使用该diff命令。
必须将显示差异的输出结果保存到~/project/config_diff.txt.
提示
该diff命令专门用于逐行比较两个文件。
基本语法是diff file1 file2，它显示了需要对 file1 进行哪些更改才能使其与 file2 完全相同。
文件顺序很重要！diff A B会diff B A影响输出结果。
diff你可以像使用 . 一样，将 的输出重定向到文件grep。
示例
对比测试环境和生产环境的配置文件后，您的~/project/config_diff.txt文件中应该显示这两个环境之间的差异：

$ cat ~/project/config_diff.txt
1,5c1,5
< # Staging Configuration
< database.url=jdbc:mysql://staging-db:3306/nexus
< api.key=staging_key_abc123
< feature.flag.new_dashboard=true
< timeout.ms=3000
---
> # Production Configuration
> database.url=jdbc:mysql://prod-db:3306/nexus
> api.key=prod_key_xyz789
> feature.flag.new_dashboard=false
> timeout.ms=5000

diff 输出显示了需要对暂存环境配置文件进行哪些更改才能使其与生产环境配置文件匹配。以 <staging_file> 开头的行显示<暂存环境配置文件的内容，而以 <production_file> 开头的行显示>生产环境配置文件的内容。这表明生产环境与暂存环境相比，使用了不同的数据库 URL、API 密钥、功能标志和超时值。

验证服务器间目录一致性

配置差异是一个重要的线索！看来生产服务器可能也缺少一些测试服务器上存在的关键文件。这可能是部署失败导致的。我们通过比较两个分别代表两台不同服务器上文件结构的目录来模拟这种情况。

任务
您有两个目录：（/home/labex/project/server1_files代表测试服务器）和/home/labex/project/server2_files（代表生产服务器）。
比较这两个目录，找出哪些文件是各自独有的server1_files。
将完整的比较结果保存到名为“.”的文件中/home/labex/project/missing_files.txt。
要求
您必须使用该diff命令来比较这两个目录。
输出结果必须保存到/home/labex/project/missing_files.txt.
提示
如果提供的是目录路径而不是文件路径，该diff命令还可以比较目录。
使用-ror–recursive选项diff比较目录是一种好做法，因为它会比较目录中的所有文件。
diff目录的输出格式将明确指出哪些文件“仅存在于”特定目录中。
就像比较文件一样，比较目录时顺序也很重要。dir1:dir2:dir1diff dir1 dir2显示的是 dir1 中存在但不在 dir2 中的内容，而 dir2:dir1:dir2 则diff dir2 dir1显示相反的内容。
示例
比较两个服务器目录后，您的/home/labex/project/missing_files.txt文件应该显示生产服务器上缺少哪些文件：

$ cat /home/labex/project/missing_files.txt
Only in /home/labex/project/server1_files: asset2.js

此输出表明，该文件asset2.js存在于第一个目录（server1_files代表测试服务器）中，但在第二个目录（server2_files代表生产服务器）中缺失。通过比较测试环境和生产环境，我们可以轻松识别生产环境中缺失的文件，这或许可以解释部分应用程序故障。

概括

出色的侦查工作！你成功地找出了凤凰项目关键故障的根本原因，并为Sundar Pichai和开发团队提供了可操作的情报来解决这些问题。

通过系统性的调查，你已经掌握了基本的故障排除命令：

grep：筛选日志文件并提取关键错误信息。
dmesg：调查系统级硬件和内核问题。
diff：比较配置文件并找出不同环境之间的差异。
命令管道和重定向：为了高效地处理和记录您的发现。
您严谨的日志分析方法避免了“凤凰项目”可能遭遇的灾难性故障。开发团队现在有了明确的方向，可以着手修复您发现的配置不匹配和部署文件缺失的问题。

莎拉·陈对你的调查能力印象深刻，她推荐你担任安保职位。明天，你将扮演堡垒守护者的角色，负责保护凤凰计划的基础设施，使其免受未来威胁！

Day4

介绍

欢迎来到 LabEx 公司的第四天，堡垒守护者！昨天你出色地完成了侦查工作，解决了凤凰计划的关键问题，公司首席技术官已亲自指派你负责整个项目的安全工作。

“我们不能再发生任何安全事件了，”首席技术官在晨会上解释道。“你们的调查显示，我们之前的安全设置不足。Sarah Chen 和开发团队需要一个万无一失的环境才能按时完成凤凰项目。”

最近的危机凸显了采取强有力的安全措施的必要性。一位新的承包商将加入团队，协助加快开发进度，您必须确保访问控制配置完善。您需要创建安全的文件系统，明确所有权归属，设置细粒度的权限，并建立协作工作空间，以保护 TechNova 的知识产权。

“凤凰计划”的成功——以及公司的未来——如今取决于你今天构建的数字堡垒。让我们一起守护这个系统！

为新项目创建安全文件

你的首要任务是创建一个文件，用于存储敏感的项目密钥。该文件必须严格保密，且只有其所有者才能访问。

任务
project_keys.txt在目录内创建一个名为“新空文件”的文件~/project/phoenix_project。
设置此文件的权限，使其仅所有者具有读写权限，其他任何人（即使是同一组中的用户）都无权访问。
要求
文件必须命名为project_keys.txt.
文件必须位于~/project/phoenix_project/project_keys.txt。
使用chmod带数字表示法的命令来设置权限。
提示
您可以使用该命令创建一个空文件touch。
记住权限的数值：读取（4）、写入（2）和执行（1）。
最终权限应为600（所有者可读写，组和其他用户无任何权限）。
示例
完成此任务后，您应该会看到类似以下内容：

$ ls -l ~/project/phoenix_project/
-rw------- 1 labex labex 0 Sep 3 16:03 project_keys.txt

文件权限显示-rw-------如下：

所有者拥有读写权限
该群组没有权限
其他人没有权限

分配项目资源的所有权

“凤凰计划”由Sundar Pichai的开发团队负责，技术负责人dev_lead管理核心开发工作。该用户属于developers您本周一直合作的团队。您需要转移所有项目文件和目录的所有权，以确保适当的访问控制。

任务
将目录及其所有内容的所有者更改~/project/phoenix_project为用户dev_lead。
~/project/phoenix_project将目录及其所有内容的所有者更改为该developers组。
要求
用户所有者必须是dev_lead。
群组所有者必须是developers。
所有权变更必须递归地应用于该目录下的所有文件和子目录~/project/phoenix_project。
你必须使用该chown命令。
提示
该chown命令可以使用特定语法同时更改用户和组user:group。
chown查找命令中允许其递归操作文件和目录的选项。该man chown命令是你的好帮手。
由于这些文件目前属于 root 用户所有，您需要使用命令sudo来更改所有权。
示例
完成此任务后，您应该会看到类似以下内容：

$ ls -ld ~/project/phoenix_project/
drwxrwxr-x 4 dev_lead developers 53 Sep 3 16:00 ~/project/phoenix_project/

$ ls -l ~/project/phoenix_project/
total 0
drwxrwxr-x 2 dev_lead developers 27 Sep 3 16:00 docs
-rw------- 1 dev_lead developers 0 Sep 3 16:03 project_keys.txt
drwxrwxr-x 2 dev_lead developers 6 Sep 3 16:00 src

所有文件和目录的所有者现在应为：

用户：dev_lead
团体：developers

确保主项目目录的安全

现在所有权已正确设置，您需要设置主项目目录的基本权限。~/project/phoenix_project策略如下：所有者应拥有完全控制权，组应能够列出文件并进入目录，外部人员应完全没有访问权限。

任务
设置目录权限~/project/phoenix_project。
要求
所有者（dev_lead）必须具有读取、写入和执行权限。
该组（developers）必须具有读取和执行权限。
其他人不得拥有任何权限。
使用该chmod命令将这些权限应用到~/project/phoenix_project目录本身（而不是递归应用）。
由于该目录的所有者是dev_lead，您可能需要使用sudo来更改权限。
提示
对目录拥有“执行”权限允许您cd进入该目录。
计算所有者、组和其他用户的数值权限值。
所有者（读写）= 4+2+1 = 7
组（rx）= 4+0+1 = 5
其他（—）= 0+0+0 = 0
示例
完成此任务后，您应该会看到类似以下内容：

$ ls -ld ~/project/phoenix_project/
drwxr-x--- 4 dev_lead developers 53 Sep 3 16:00 ~/project/phoenix_project/

目录权限显示drwxr-x—如下：

所有者（dev_lead）拥有读取、写入和执行权限
组（developers）拥有读取和执行权限
其他人没有权限
这意味着：

dev_lead可以完全访问该目录
developers群组成员可以列出内容并进入目录。
外部人员无权访问该目录。

other way:

为开发团队设置协作权限

注意：请确保您已先完成步骤 2，该步骤会将所有项目目录（包括src）的所有权设置为dev_lead:developers。此步骤基于这些所有权设置。

开发团队需要在该~/project/phoenix_project/src目录下高效协作。为确保协作顺畅，在该目录下创建的任何新文件或目录src都应自动归属于该目录所属的developers组，而不是创建该文件或目录的用户所属的主组。

任务
对目录设置特殊权限~/project/phoenix_project/src，强制其中创建的所有新文件和子目录继承src目录本身的组所有权（即developers）。
要求
该解决方案必须确保新文件~/project/phoenix_project/src自动归属于该developers组。
您必须使用chmod命令来设置此特殊权限。
您可能需要使用该工具sudo来设置其他用户拥有的目录的权限。
提示
这种特殊权限称为“设置组 ID”或setgid位。
您可以setgid使用符号（g+s）或数字表示法来应用该位。
用数字表示法表示，该setgid位的值为2。它位于标准的三个权限数字（例如，2770）之前。
示例
完成此任务后，您应该会看到类似以下内容：

$ ls -ld ~/project/phoenix_project/src/
drwxrws--- 2 dev_lead developers 6 Sep 3 16:00 ~/project/phoenix_project/src/

组执行位置s表示 setgid 位已设置，并且该组具有执行权限。现在，当您创建一个新文件时：

$ touch ~/project/phoenix_project/src/new_file.txt
$ ls -l ~/project/phoenix_project/src/new_file.txt
-rw-rw---- 1 dev_lead developers 0 Sep 3 16:05 new_file.txt

developers请注意，即使您以其他用户身份登录，新文件也会自动归属于该组。这既能确保开发团队内部的协作，又能维护正确的组所有权。

权限显示如下：

所有者（dev_lead）拥有读写权限
组（developers）拥有读写权限
其他人没有权限
s组执行位置的小写字母表示 setgid 位已设置，并且该组具有执行权限。

概括

Fortress Guardian，干得漂亮！你们成功地为“凤凰计划”构建了坚不可摧的安全基础。首席技术官和Sundar Pichai对你们全面的安全部署赞叹不已。项目目录现在就像一座堡垒，既能保护TechNova的知识产权，又能实现无缝协作。

在整个挑战过程中，你已经掌握了关键的Linux安全技能：

创建文件和基本权限：您使用精确的权限控制保护了敏感的项目密钥。
所有权管理：您巧妙地将所有权分配给了 Sarah 的开发团队和技术领导层。
目录安全：您平衡了主要项目基础设施的访问权限和安全性。
高级权限：您已配置 setgid 权限，以确保协作团队工作区具有自动组所有权继承功能。
协作工作空间：您配置了团队协作空间，既能保证安全性，又能提高生产力。
这些高级安全技能证明您已具备担任高级系统管理员的资格。明天，您将作为“密钥保管员”迎接最终挑战，通过控制系统用户访问权限来管理“凤凰计划”安全中的人为因素！