そのため、/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ボックスにはルートパスワードがないようです。そのため、su -
私が目にするもう 1 つのことは、コンピューターを再起動して、パスワードをリセットできるシングル ユーザーの操作を実行することです。大きな問題は、これが Amazon EC2 であり、私は単にボックスに SSH 接続しているだけで、物理的にアクセスできないことです。
質問です。私は完全にダメになってしまったのでしょうか、それとも回避策があるのでしょうか? これは Ubuntu ではなく、CentOS のようです。 についても今は理解していますvisudoが、変更を行ったサイトにはそのことが書かれていませんでした。
答え1
一度、まったく同じ方法でインスタンスを台無しにしてしまったことがありますが、別の稼働中のインスタンスから EBS ボリュームをマウントすることで回復できました。これには多くの手順が必要です。
- EC2マネジメントコンソールからEC2インスタンスを停止します
- ボリューム画面に移動し、問題のあるEBSボリュームをインスタンスからデタッチします。
- デフォルトのオプションで標準の Linux AMI を使用して、新しいマイクロインスタンスを起動します (既に別の稼働中のインスタンスがある場合を除く)
- 新しいインスタンスが実行されるやいなや、問題のあるEBSボリュームをそれに接続する
- それから取り付ける
ディレクトリとしてマウントしたら、新しいインスタンスから問題のあるボリュームのファイルシステムにアクセスしてファイルを修正できるはずですsudoers。その後、ボリュームをアンマウントしてデタッチし、他のインスタンスに再アタッチするだけです。