一旦创建了恢复实例...

一旦创建了恢复实例...

背景故事:我试图让 PHP 执行节点,但最终更改了可能比我应该更改的更多的文件和文件夹的权限/所有权。

有一次我偶然听到有人建议我进行更改,/etc/sudoers/以便将其设置为Defaults requiretty。我试图nano将其改为 ,但做不到。于是我就想到了sudo chown ec2-user /etc/sudoers,从那以后我就一直被这个问题困扰着。

在此处输入图片描述

我可以返回 nano 并恢复我的文本更改,但是文件的所有权是现在导致问题的原因。

我认为他在这里回答的最接近的问题是这个:
亚马逊网络服务 ec2 Linux CentOS 上的 sudo 损坏(但这个与解析错误有关,我假设是文件中的拼写错误)。

我该如何修复这个问题?我是不是彻底搞砸了这个 EC2 实例?

答案1

虽然阅读亚马逊文档很有帮助(根据@Ouroborus 的回答),但我终于明白了如何解决我自己陷入的这个困境。

让我们看看我是否能回忆起所有的步骤......

  • 准备新实例

    • 尽可能匹配现有实例的最简单方法是我的 AMI并选择问题实例使用的相同 AMI 映像。


      在此处输入图片描述

    • 由于这只是一个用于恢复目的的实例,请选择自由的实例类型:

      在此处输入图片描述

    • 此步骤是很重要!确保此恢复实例中的子网掩码与问题实例相匹配(否则,您将无法将问题 EBS 安装到恢复实例!我发现这很困难......)

      在此处输入图片描述

    • 您可以单击“下一步:添加存储”,保留该页面原样,然后单击“下一步:标记实例”。

    • 在值字段中,输入类似“Recovery”的内容(任何名称都可以,在我的情况下,它只是为了标记此实例的用途)。

      在此处输入图片描述

    • 最后一步/弹出窗口会提示您创建入站/出站安全组。请确保选择与您之前创建的相同的安全组应该已经为您的问题实例设置了设置。这意味着,您可以重复使用相同的 SSH 密钥文件登录此实例(通过 Putty 或您喜欢的任何程序)。

一旦创建了恢复实例...

  • 确保跟踪您的 EBS 卷名称(因为您需要在此临时实例和原始实例之间挂载/卸载问题卷)。
  • 标记出你的路径问题实例访问卷(例如/dev/xvda:)。
  • 现在可以停止(不是终止!!!)您的问题实例。
  • 您可能需要刷新浏览器以确认它已停止(可能需要几秒钟/几分钟)。
  • 现在导航到 EBS 卷部分:

    在此处输入图片描述

  • 卸载当前连接到问题实例的卷(您将看到实例的状态标记为停止在最右边的一列中)。

  • 刷新以确认该卷“可用”。
  • 将卷安装到新的恢复实例(如果您在列表中看不到恢复实例,您可能错过了我上面提到的“子网”步骤 - 并且您需要重新执行恢复实例以匹配该子网设置)。

  • 刷新,确认它现在在您的恢复实例中“正在使用”。

  • 现在,开始有趣的命令行步骤!

    • 登录/SSH 进入您的恢复箱(您可以在实例部分)。

    • 将当前工作目录设置为根目录:
      cd /

    • 创建一个目录来保存有问题的 EBS 卷:
      sudo mkdir bad

    • 安装它: sudo mount /dev/xvdf /bad

      (注意:如果这不起作用,你可能遇到了和我一样的问题,所以请尝试以下方法:sudo mount /dev/xvdf1 /bad,感谢这个答案https://serverfault.com/a/632906/356372)。

    • 如果一切顺利,你现在就可以光盘进入该/bad目录并查看在原始(当前有问题的)实例上安装时通常会看到的相同文件结构。

    • 很重要请注意,在以下几个步骤中,我如何使用./etc而不是/etc指示修改文件的权限/所有权/bad/etc/sudoers,而不是此恢复 EBS 卷!一个损坏的卷就够了,对吧?

    • 尝试:
      cd /bad
      ls -l ./etc/sudoers
      ...然后按照:
      stat --format %a ./etc/sudoers

    • 确认该文件的所有权和/或chmod值确实不正确。

要修复其chown所有权,请执行以下操作:

sudo chown root:root ./etc/sudoers

要修复其chmod值,请执行以下操作:

sudo chmod 0755 ./etc/sudoers

现在只需逆转步骤即可!

  • 一旦完成,就可以卸载了: cd /
    sudo umount /bad

  • 返回 AWS 配置页面,转到 EBS Volume 部分。

  • 卸载固定的来自恢复实例的卷。
  • 刷新,确认是available
  • 将其重新安装到原始实例上(不要忘记 - 使用/dev/whatever/原始实例在执行所有这些步骤之前使用的相同卷路径)。
  • 刷新,确认是in-use
  • 现在,导航至实例部分和开始您的原始实例。(重新启动可能需要几秒钟/几分钟)。
  • 如果一切顺利,您现在应该能够登录并通过 SSH 进入您的 EC2 实例并sudo再次使用!

如果它也对你有用那么恭喜你!

如果没有....我很....很抱歉这件事发生在你身上 :(

答案2

是的,你把它搞坏了。由于所有权原因,你无法使用 sudo,而且 Amazon 的实例设置为不允许没有 sudo 访问权限的 root 用户。

如果重新启动实例不起作用,那么您所做的更改将存储在您附加的 EBS 卷上。修复它需要启动另一个新实例,并使用它来安装和更改包含损坏文件的 EBS 卷。这样做是在亚马逊自己的文档中描述总结在你链接的问题的答案中

修复该问题后,但在尝试/etc/sudoers再次编辑之前,请阅读visudo,这是一种将您置于预加载的编辑器中的工具,/etc/sudoers它会在保存之前执行健全性检查。

相关内容