web-dev-qa-db-ja.com

アマゾンウェブサービスec2linuxcentOSで壊れたSudo

そのため、/ etc/sudoersファイルをいじる危険性についてはまったくわかりませんでした。そこで、単純な変更を加えようとしていました。ただし、構文が正しくないものを入れたようで、次の問題が発生します。

$ Sudo
sudo: >>> /etc/sudoers: syntax error near line 122 <<<
Sudo: parse error in /etc/sudoers near line 122
Sudo: no valid sudoers sources found, quitting
Sudo: unable to initialize policy plugin

ルートアクセス権がないため、/ etc/sudoersファイルを編集できなくなりました。

私がオンラインで見る1つの修正は、使用することです。

$ su -

ルートパスワードを入力します。ただし、このAmazon ec2ボックスにはrootパスワードがないようであるため、su -を使用できません。

私が見るもう1つのことは、コンピューターを再起動し、パスワードをリセットできるシングルユーザー操作を実行することです。大きな問題は、これがAmazon ec2であり、ボックスにSSHで接続しているだけで、物理的にアクセスできないことです。

質問、私は完全にねじ込まれていますか、それとも可能な回避策はありますか？これはUbuntuではなく、CentOSのようです。 visudoについても理解できましたが、変更を取得したサイトにはそのことが記載されていませんでした。

linuxcentossudoamazon-ec2sudoers
2
Evan

一度まったく同じ方法でインスタンスを台無しにしましたが、別の動作中のインスタンスからEBSボリュームをマウントすることでインスタンスを回復できました。関係する多くのステップがあります：

  • EC2管理コンソールから、EC2インスタンスを停止します
  • [ボリューム]画面に移動し、問題のあるEBSボリュームをインスタンスからデタッチします
  • デフォルトのオプションを備えたストックLinuxAMIを使用して、新しい新しいマイクロインスタンスを起動します（すでに別の作業インスタンスがある場合を除く）
  • 新しいインスタンスが実行されたら、 問題のあるEBSボリュームをインスタンスに接続します
  • 次に マウントする

ディレクトリとしてマウントされると、問題のあるボリュームのファイルシステムに新しいインスタンスからアクセスして、sudoersファイルを修正できるようになります。次に、ボリュームをアンマウントしてデタッチし、他のインスタンスに再接続します。

3
David Levesque