rootとしてログインしているときに、誤って行った最も愚かなことは何ですか。また、どのように回復しましたか。
この質問は歴史的に重要であるために存在しますが、このサイトにとって適切なトピックの質問とは見なされないため、ここで同様の質問をすることができるという証拠として使用しないでください。
テストシステムがログインするためにドメイン管理者を必要としたため、私はかつて本番SQLサーバーシステムのインデックスを誤って削除しました。それらを再構築するためにすべての月曜日の朝を取りました。
chown randomuser /* -R
の代わりに
chown randomuser ./* -R
kill 1
の代わりに
kill %1
ルートとして。 initとそのすべての子が死ぬ...
これは、200kgの羊毛の俵を選別する150メートルほどの長さの選別機を制御するLinuxボックスでした。
マシンが少しずつ裂ける前に、オペレーターコンソールの大きな赤い緊急停止を使い果たして押すことで回復しました。
時々、あなたが回復できるのはこれまでのところだけです。 ;-)
Rootとしてログインしているときに、誤って「root」ユーザーを削除してしまいました。 Red Hatボックスは、PSUが死ぬまで、隅で静かにqmailを実行し、さらに6か月間実行されました。考えてみるとまだ赤面しています。
2つのこと：
ある仮想端末でフルスクリーンSSHセッションを実行し、別の仮想端末で他のタスクを実行します。どのVTを使用しているかがわからず、FDISKを実行し、HDBのすべてのパーティションをワイプしてから、再起動しました。そのサーバー上のすべてのユーザーデータを吹き飛ばしました。（問題のサーバーが復旧したときにパーティションの正確なジオメトリが仮想端末に表示されていたため、すべてを取り戻すことができました。フォーマットせずにパーティションを再作成しました。すべてのデータはそこまで）
カーネルのコンパイルに失敗した試みをクリーンアップしようとして、現在実行中のカーネルのすべてのモジュールバイナリを吹き飛ばしました。たまたまカリフォルニアのどこかのデータセンターにあったサーバーを再起動した後で初めて気づきました。唯一の問題は、私がオーストラリアのキャンベラにいることです。
必ずしもログインしている必要はありませんが...
90年代初頭、私はミシガン州の非常に尊敬されている大学で働き、IT部門内のコミュニケーションにトランシーバーを使用しました。ある日、私はサーバールームに足を踏み入れ、トランシーバーに鍵をかけ、ブームを起こしました。20台のサーバーすべてが同時に再起動しました。
言うまでもなく、無線機はサーバールームに再び入ることを禁止されました。
メールサーバーではrm-rf *の代わりにrmrf /。新しい仕事に就き、必要なときだけSudo/bin/bashを学ぶことで回復しました。
新しいユーザーアカウントを設定し、誤ってユーザーのパスワードではなくrootパスワードを設定してしまいました。ユーザーはアカウントを必要とせず、パスワードが失われ、何ヶ月もの間rootとしてボックスにログインしていませんでした。数か月後、rootアクセスを必要とする変更を加えて変更する必要があったときに、パスワード回復を行う必要がありました。プロダクションボックスだったので苦痛だったので、rootパスワードを回復するためにほんの数分でもそれを削除するのは悪かったです。
私はただのテクニカルライターなので、あなたが何について話しているのかを知るのに苦労することがあり、実際のキットの近くでリモートで危険なことをすることは決して許されません。しかし、前の仕事（非常に前の-続きを読む）で、私はここケンブリッジサイエンスパークにいるVerka S（キャッチフレーズは「良いコードは注釈を必要としない」でした）と呼ばれる特定のプログラマーを思い出します。彼女の勝利3.11ボックスが機能しなくなった理由を理解してください（それは非常に前だったとあなたに言いました）。死んだ物体を簡単に調べた後、彼は「あなたは何をしましたか？」と尋ねました。彼女は「ハードディスクの空き容量を増やしようとしていたので、見つけた最大のファイルを削除しました」と答えました。 「それが何と呼ばれていたか覚えていますか」とsysadminに尋ねました：「はい」彼女は行きます：「win.exe」。彼女のコードには確かに完全な注釈が必要だったと推測するのは正しいでしょう。
IRCチャネルで誰かがPerlを実行したところ、 "rm -rf /"を実行するのに注意が必要でした。
長い夜を過ごした後、その朝カフェインが不足した後、私は誤って走りました
rm -R web/*
の代わりに
rm -R _web/*
バックアップフォルダではなく、クライアントサイト全体を削除しました。この時点で、バックアップ戦略に大きな欠陥があることに気づきました。オフサイトのコピーは古く、サーバー上のバックアップはダウンロードしてアクセスできない8GBのファイルに保存されていました。ファイル名にスペースがあるため、ディレクトリ全体を復元できず、代わりに各ファイル名を指定する必要がありました。手動で二重引用符で囲みます。ファイルを1つずつ復元するプロセスを自動化するためだけに、スクリプトを作成するのに数時間かかりました。
VmwareゲストVMのディスクイメージファイルを削除しました。バックアップがありませんでした。
幸い、ゲストはまだ実行されていたので、新しいVMでゲストをバックアップして復元することができました。 2年後もまだ稼働しています。
しかし、最悪の事態は私がログインしたときではありませんでした。私は物事をラック内で動かし、突然、昨年のアーカイブを含む500GBの外部ディスクが3人の顧客のために床に落ちました。全部なくなった。そしてそれはダブルディスク、RAID1でした。 RAID1がディスク障害の包括的な解決策ではなかったという難しい方法を学びました;）
間違ったコンピューターを誤ってシャットダウンしました。それは職場のプロキシサーバーへのssh接続でした。ラップトップをシャットダウンしたかったのですが、代わりにインターネットなしで50人を配置しました。サーバールームに実行してサーバーを再度起動することで回復しました。
一緒に働いていた誰かがパスワードファイルを削除してから、重要な本番Sunサーバーからログアウトしました。ただ再インストールすることができなかったので、私はそれを修理しなければなりませんでした。
別の管理者が、メインの本番データベースと同じuidとホームでアカウントを作成してから、コピーアカウントを削除しました。データベースのユーザーとホームを削除しました。これはノンストップのタンデムで、管理者の顔にエッグがあり、停止させました。
一時ファイルが多くのスペースを占める理由がわからなかったので、Sunサーバー上のAppleファイルからリソースフォークを削除しました。Macユーザーは感心しませんでした;）
ファイルサーバー上のすべてのファイルを再帰的に削除するスクリプトを実行しました。
ファイルの部分的なバックアップがあったため、完全に回復することはできませんでした。
パッチを適用したいくつかのサービスを再起動するためにinit1に行きましたが、SSHで接続されていて、サーバーまで車で3時間離れていることを忘れていました。幸いなことに、翌日その場所へのサービスコールがあり、問題のサーバーは本番環境ではなくバックアップでした。
パッチ適用後にワークステーションを再起動しているときに、すべて（20）の運用サーバーを誤って再起動しました。サーバー名は、スクリプトのフィード元のテキストファイルに含まれていました。
それは稼働時間を殺しました、それはその組織ではそれほど大したことではありませんでした..しかしExchangeはそれ自身で戻ってきませんでした-それはそれが翌朝気づいた方法でした。 （技術的には「root」ではありませんが、ドメイン管理者は重要ですよね？:)）
Sudo rm -Rf/*
Windows 2003Serverでハードドライブをダイナミックディスクに変換しました。間違ったハードドライブを除いて、それは正しいことでした。最初は何をすべきかわからなかったので、データを取り戻すのに少し時間がかかりました。
ホームサーバーで、パーティションのサイズを変更するときに、&&と一緒にあまりにも多くの重要なコマンドをチェーンしました。 （引数を除いて）fsck && resize2fsで、次の行にlvreduceが続くと思います。 fsckは、私が想定していた終了コードを返さなかったため、resize2fsは実行されず、lvreduceは、ボリュームを切り捨てたときに大量のデータを完全に無駄にしました。
最近は&&にもっと気をつけています。