HP社によるbashシェルスクリプトのリリース手順ミスにより京都大学学術情報メディアセンターのLustreファイルシステム上の77TBのファイルが消失

自動ニュース作成GHP社によるbashシェルスクリプトのリリース手順ミスにより京都大学学術情報メディアセンターのLustreファイルシステム上の77TBのファイルが消失https://www.iimc.kyoto-u.ac.jp/services/comp/pdf/file_loss_insident_20211228.pdf2021-12-29 10:00:36＞バックアップスクリプトには、find コマンドにより 10 日以上古いログファイルを削除する処理が含まれています。スクリプトの機能改善と合わせて、find コマンドの削除処理に渡す変数名を視認性・可読性を高めるため変更いたしましたが～
＞bashは、シェルスクリプトの実行中に適時シェルスクリプトを読み込みます。この挙動による副作用を認識できておらず、実行中のスクリプトが存在している状態でスクリプトの上書きによりリリースしてしまったことで、途中から修正したシェルスクリプトの再読み込みが発生し、結果的に未定義の変数を含む find コマンドが実行されてしまいました。
このbashの仕様、俺も知らなかったわ。俺もやらかしてたかも知れないな。・年末になんちゅう心臓に悪い記事を見せてくれるんや...・推測だけど、find /LARGE0 -name '*.log' -type f -mtime 10 | xargs rm -rfとかになってたスクリプトをTARGETFILE='*.log'～find /LARGE0 -name ${TARGETFILE} -type f -mtime 10～みたいに書き換えたのかなぁ。・HPはおそらくサーバの保守を担当していたのだろう。bashの問題ではなく、スクリプトの更新手順が悪かったようだな。難しい話ではなく、プリコンパイルやらセッションやらの概念が無い言語一般の話で、ループの中なんかでスクリプトを実行する度に読み直すというだけの話ではないかな。呼び出し元のスクリプトの話ではないのでは？・復旧できないデータが本当の被害内容だと思うけど、直接は書いてないね。わざとかな。77T-49T=28Tが真の被害内容になるんかな。・#4 復旧できないデータ量としてはそうでしょうね。・ここのシステムぐぐったので貼っておく。システム全体は https://www.iimc.kyoto-u.ac.jp/ja/services/comp/supercomputer/ それを見ると使ってるストレージはここか。 https://ddn.co.jp/products/storage_software/exascaler.html 利用者向けのストレージの利用説明はここ https://web.kudpc.kyoto-u.ac.jp/manual/ja/filesystem・これさ。スクリプトが動作する権限設定がおかしいのよ。ログ管理用のアカウントを払い出して、それでログの範囲でしか処理できないように作らなきゃいけなかった。ログファイル以外も削除するってことは、rootアカウントとかで動かしてたんじゃないかね。どうみても根本原因仕様バグです。実行中うんぬんは運用の問題。・ド素人の感覚でも「なんでそんな上位の権限が付与されてるんだよ」としか思えないんだが、その辺の詳細が知りたいわ・禁断のUNIXコマンドを実行しちゃった感じ？・https://sleepy-yoshi.hatenablog.com/entry/20090917/p1シェルスクリプトは文字通りの逐次実行・#7-8 確かにそんな気もしますね。#10 おお！俺もブログ主と同じくメモリに全読みしてると思ってた。・ダイナミック・リンクとスタティック・リンクを間違えてコンパイルした夢を見た。疲れているのかな・・・。・PC-watchでも取り上げられた。『日本ヒューレット・パッカード製ソフトの不具合で京大スパコンのデータ77TBが消失』 https://pc.watch.impress.co.jp/docs/news/1378005.html ソフトの不具合か・・・。・この間3TバイトのHDDが吹っ飛んだ自分には笑い事じゃないわ…・Windowsのバッチファイルも途中で書き換えるとおかしくなる。・ITmediaにも載った。『京大スパコンのデータ77TBが消失　バックアップ処理中に不具合　日本ヒューレット・パッカード「100％弊社の責任」』https://www.itmedia.co.jp/news/articles/2112/29/news040.html