「var」の記事 - Crieit

大事なサーバの/varを消した話。悪夢の無限列車編👹

2021-06-15T00:24:38+09:00

お久しぶりです！
ここの所、立て込んでいたり（表題の件で）、メンタルやられ気味だったり（表題の件で）で余裕がなかった私です。

あれほど講師の方に、「rmを使うときは気を付けよう」と言われていたのに…

v目次にゃv

1.どんなサーバなのか
2.CentOSの/varを消したお話ー悪夢の始まり無限列車編
3.CentOSの/varを消したお話ー血鬼術の落とし穴編
4.消した後ーお前ももうおやすみ・・・
5.起こったこと
6.復旧作業
7.結末
8.考えられる復元法
9.回避の呼吸！型集

どんなサーバなのか

私はゲーム制作サークルのサーバ担当（仮？）をしてますねこー。
ざっくり挙げると
・ホームページ
・工程、プロジェクト管理ソフトの管理
・Gitサーバ
を管理をしているきんぎょ。
昔はメールサーバもやっていたけど色々考えて、Google Workspaceと兼用させてるぎょぴ。

ちなみに、VPSでCentOS7をつかっていますきんぎょ。
これは消してはいけない。障害を起こしてはダメなやつだ（）

CentOSの/varを消したお話ー血鬼術の落とし穴編

先ほど紹介したrm -rf /var/hogehoge/＃抹消対象＃　の血鬼術ですが、重大な"欠陥"がある鬼～。
そう、"血"鬼術だけに…（欠陥と血管をかけた）

基本的にLinuxにはWindowsでいうゴミ箱が存在しないきんぎょ。
つまり、消したものは、ほぼ二度と元には戻りません。

今回の落とし穴（後悔ポイント）

・cdで/varに移動して作業していれば消えるフォルダは最小で済んだ
・脳死でポチポチやっていた
・脳死のためエンターキーとTabキーを間違えた

抹殺対象を消すために、1つ1つ手打ちで打っていたわけです。正規表現しようにも、ダブりで消せないファイルもあるので…
数もそれなりにあるので、脳死状態でポチポチ術を発動していきます。Tab変換を活用して…

rm -rf /var　エンターキーポチッ！＼(^o^)／ｱｯｵﾜｯﾀ
実行した瞬間、理解できず、思考がグルグル走馬灯。一瞬が5分くらいに長く感じ、冷や汗が全身をつたいました。

消した後ーお前ももうおやすみ・・・

/varを消した直後、
”今動いているシステムは消せないよ”とのメッセージが。
lsで確認するとtmp以外消えている！！！！！！！！！
【VirtualBoxで再現した写真↓もちろん今回はバックアップをとってある】
!

起こったこと

・/varに配置しているものは全て消失しました。
→ホームページの消失
→行程、プロジェクト管理のデータ消失（Webで動作するもののため）
→プロジェクト管理のデータベース消失
・yumが死んだ。（rpmもだめ）
・firewallが起動できない（iptablesはギリ生きていたっぽい？）
・SSHアクセスが弾かれる
・私は内心大泣き
・私、汗だく

・gitも死んだと思っていたら、/var以外の場所で管理していたのでセーフ（本当に良かった。）
・wgetやcurlは使用可能

復旧作業

どうやらextundeleteコマンドで復旧可能らしい！
標準では入っていないので、yum install extundeleteで導入します！
＿人人人人人人人人人人人＿
＞　yumが使えない！！　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
はい。終わりました。
どうやらyumにかかわるデータが/var以下にあったようで、正常に動作しなくなりました。

他にデータ復元方法はいくつかあり、試しましたが全部だめでした。
他のcentから消えたデータを移植したり、リカバリーモードを起動したり、OSの書き換えを試みたり…

結末

結局、新しくサーバを立て、生きているデータを故サーバからサルベージ。移行する手段を取りました。
VPSという特性上いろいろ気を遣う作業が多かったです。（今回ばかりはハードを直で触れる自宅サーバを羨みました。）

考えられる復元法

私の知識、経験不足ゆえに、実現しませんでしたが、この状況でも復活できる可能性はありました。
・wgetやcurlを使って修復系パッケージの導入
・健全なサーバより消滅したデータを移行。権限や依存関係も手動で設定
・パーティションやプロセスから復元
いずれも果てしない労力と戦場で培うべき経験、正しい知識が必要なためペーペーの私は力尽きました…

今から大事なことを書きます！
・rmコマンドの扱い
まずはrmコマンドを使うときは慎重に行きましょう。絶対です。
特に-rf オプションを使うときは要注意です。なんでも消せちゃいます。イレイザーヘッドです💦
・バックアップを取っておく
何事も作業前にバックアップを取っておきましょう。VirtualBoxならスナップショット。VPSならイメージOSの保存とかね。
・extundelete等の復元ツールは予め入れておく
ことが起きてからでは遅いです。今回みたくyumひいてはOSそのものがダウンして緊急時には何が使えなくなるか分かりません。前もって対策しておきましょう。
・実験環境を用意、活用する
普通なら本番と全く同じ実験環境（兼バックアップ）を利用すべきです。コストがかかるのは仕方ないですが、データ復旧費や今までの労力が水の泡になるよりは安いです！
サークル活動でのリアルな実験環境費用捻出は難しいですが…
本当に業務上じゃなくてよかった…
・ある程度子ディレクトリに入って作業をする
今回は絶対パスで/varと打っていたのも原因の1つです。
仮にvarにい状態で作業していればvarそのものが消えるという事態は避けられていました。

エンドタイトル

ということで悪夢の無限列車編を締めくくりたいと思います。
何かあってからでの対策では遅いということを痛感しました。
色々やばすぎて、語尾を忘れるくらいですからきんぎょ。
本当に業務での失態でなくてよかったです…おそらく私じゃ払いきれない額の損害でしょうから（震え）
さらに辛かったのが「var消しちゃった💦」で検索してもヒットしなかったことです。varを消す馬鹿野郎は私くらいということですかね～（すっとぼけ）

今回はここまで🐾
みなさん、私の屍を超えていけ！！！！

【C#】varの使い方、メリットとデメリット

2021-01-06T20:08:06+09:00

使い方

C#では変数宣言時、型を書く必要がある。

string text = "あいうえお";

この時、varキーワードを使用することで右辺から型を推論させて変数宣言を行える。

var text = "あいうえお";

// textはstring型となる

Visual Studioで確認すると、string型となっていることがわかる。

varは右辺から型を判別している。そのため、下記のコードはコンパイルエラーとなる。

var text = null;

// nullの型を判別できないためコンパイルエラーとなる

もしstring型のnullをvarを使って宣言する場合、下記のように書かなければならない。

var text = (string)null;

この記法だと一応宣言はできるが、あまり型推論のメリットがない。（後述するようにメリットがない訳ではない）

メリット

varを使うと次のメリットがある。

複雑な型名を書かなくても良い
型が変更されたときに書き直さなくても良い
コードが読みやすくなる

順番に解説する。

複雑な型名を書かなくても良い

たとえばDictionary, string>, Dictionary, Dictionary>>を返すNegativeMethodという関数があるとしよう。

これもvarを使うと型名を書かなくてよい。

public static Dictionary, string>, Dictionary, Dictionary>> NegativeMethod()
{
    Dictionary, string>, Dictionary, Dictionary>> something = new Dictionary, string>, Dictionary, Dictionary>>();

    // ～複雑な処理

    return something;
}

Dictionary, string>, Dictionary, Dictionary>> result = NegativeMethod();

上記のようなコードが、下記のように書ける。

public static Dictionary, string>, Dictionary, Dictionary>> NegativeMethod()
{
    var something = new Dictionary, string>, Dictionary, Dictionary>>();

    // ～複雑な処理

    return something;
}

var result = NegativeMethod();

型が明確になっている場合は、複雑な型を書かなくて良くなる。TupleやDictionaryは複雑になる場合もあるが、それをいちいち書かなくても良いメリットとなる。なお、後述するがこういう使い方にはデメリットもあるので注意。

型が変更されたときに書き直さなくても良い

たとえばuserIdはint型だったが、アルファベットを含めるという仕様変更にあたりstring型に変更することになったとする。

ここで、下記のように修正する必要がある。

// GenerateUserIdはintを返す
int userId = GenerateUserId();

// ▲これを下記のように変更する▼

// GenerateUserIdはstringを返すようになった
string userId = GenerateUserId();

数か所であれば問題ないがもし何十箇所・何百箇所も記載してあればそれらを漏れなく修正する必要がある。

一括で置換するという方法もない訳ではないが、対象が漏れなく置換されたか、本来修正範囲外のコードが変更されていないかなどの差分確認の作業が結局発生する。

初めからvarで記載しておけば型が変更されてもコードの修正が必要なく、修正後にテストを走らせればそれだけで済む。

// GenerateUserIdがintからstringになっても、ここは修正する必要がない
var userId = GenerateUserId();

コードが読みやすくなる

ここは感覚的な問題だが例を示す。

下記のようなコードがあるとする。

int userId = GenerateUserId();
string firstName = "";
string lastName = "";
DateTime birthday = new DateTime(1990, 1, 1);

これはvarを使用すると次のように書ける。

var userId = GenerateUserId();
var firstName = "";
var lastName = "";
var birthday = new DateTime(1990, 1, 1);

こうすると型の部分が全てvarになり、変数名のインデントが揃って読みやすくなる…気がする。少なくとも私は、バラバラに型を書いているよりvarで揃っていた方が読みやすい。

デメリット

上記のようにとてもメリットの大きなvarだが、デメリットとなるケースも存在する。

それは、人間が容易に型を推論できない場合だ。

var firstName = GetFirstName(userId);

上記の場合、おそらくfirstNameはstring型になるだろうという想像が出来る。varを使用するのが相応しいケースの一つだ。

しかし下記の場合はどうだろう？

var idAndNames = GetIdAndNames();

GetIdAndNamesはおそらくidとnameを（おそらくペアで）取得するメソッドだと予想はできるが、どういう型になっているかは実装部分を見ないと判定できない。DictionaryかもしれないしList>かもしれない。独自クラスのコレクションになっている可能性もある。

varを使用したらGetIdAndNamesがどのような型を返すとしても寛容に受け入れてしまう反面、型が分かりにくくなるというデメリットもある。(上記の例は関数名などのネーミングの問題もあるが)

Visual StudioなどのIDE上で読むのであれば、変数名にマウスオーバーしたら型が分かるが、バージョン管理ソフトの履歴などの画面では当然そのような機能がないため読みづらい。型が分かりにくい場合は型を明記するが、コメントを添えておくと良いだろう。

コメントは後で型が変わった時などにメンテしなければならないので、明記する方が個人的には良いと思う。型を明記していればコンパイルエラーなどで検知できるので修正漏れを防ぐ助けにもなる。

// varを使わず型を明記する場合
Dictionary = GetIdAndNames();

// コメントを添える場合
// GetIdAndNamesはDictionary
var idAndNames = GetIdAndNames();

`var`は使うべきか

これはもちろんチームのコーディング規約や方針に従わなければならないが、少なくとも私は個人開発では積極的に利用する。私がアサインされたチームでも今のところ「varは禁止」というところはなかったので非常に助かっている。

MicrosoftのC# のコーディング規則 (C# プログラミングガイド)にも、

変数の型が割り当ての右側から明らかである場合、または厳密な型が重要でない場合は、ローカル変数の暗黙の型指定を使用します。

と明記されている。

「var」の記事 - Crieit

大事なサーバの/varを消した話。悪夢の無限列車編👹

【C#】varの使い方、メリットとデメリット

varは使うべきか

`var`は使うべきか