元システム管理者のブログ

 システム関係の人間は知っている、1GB=1024KBであること。 ところが、G（ギガ）とかK（キロ）とかはメートル法なので本当は1GB=1000KBなのだそうだ。HDDの容量とかで500GBと書いてあるが、実際は465GBぐらいしか使えません。 この表記の二重表記はしょうがないと思ってましたが、AWSでの容量表記がGiBなるものがあって調べてみたら、20年以上前に作られていたことが判明。 したがって、メートル法で表記する場合はGB。 ちゃんと2進法の容量で表記する場合はGiBと決められていたそうだ。 でも全然滲透していないので混乱するよねー。 以下に記録しておきます。 GBからGiB、GiBからGB 1GBは1GiBの0.93倍（厳密には0.931323倍）です。 GBからGiBへはこの値を掛けて、GiBからGBへはこの値を割ってください。 TBからTiB、TiBからTB 1TBは1TiBの0.909495です。TBからTiBへはこの値を掛けて、 TiBからTBへはこの値を割ってください。 GiBからTiB、TiBからGiB GiBからTiBに変換する場合は1,024で割り、 TiBからGiBに変換する場合は1,024を掛けます。 測定単位 バイト キロバイト(kB) 1,000¹ = 1,000 メガバイト(MB) 1,000² = 1,000,000 ギガバイト(GB) 1,000³ = 1,000,000,000 テラバイト（TB） 1,000⁴ = 1,000,000,000,000 ペタバイト（PB） 1,000⁵ = 1,000,000,000,000,000 測定単位 バイト キビバイト(KiB) 1,024¹ = 1,024 メビバイト(MiB) 1,024² = 1,048,576 ギビバイト（GiB） 1,024³ = 1,073,741,824 テビバイト（TiB） 1,024⁴ = 1,099,511,627,776 ペビバイト（PiB） 1,024⁵ = 1,125,899,906,842,620

 ある日突然、IMEの辞書の登録がなくなっているとの連絡あり。 ユーザー辞書の場所を確認すると、数日前にTMPファイルが存在したので、どうやらシステムエラーを起こした際にバックアップが自動的に取られて、ユーザー辞書がリセットされたようだ。 ユーザー辞書をリネームして、TMPファイルの名前をユーザー辞書の名前にリネームして復元できた。

 Deep Securityの初期設定自体は業者に依頼しているため、AWSのホスト名がそのままコンピュータービューに表示されて、なんの用途のサーバーかわかりずらいとずっと思っていた。 コンピューターをダブルクリックすると「表示名」と「説明」が追記できるため、 「表示名」に用途、「説明」に設置場所と役割を追記した。 するとコンピュータービューの名前欄が「ホスト名」＋（表示名）と表示された。これは大変便利になった。イベントビューの対象欄などすべてが同じ形で表示されるのでコンピュータ名を選択するのも格段に使いやすくなった。 説明してくれよーー( ..)φメモメモ

 オンプレミスのeKeihiの駅すぱあとはデータを手動で更新するのが面倒。 ヴァル研究所から年間保守更新の案内あり。それに駅すぱあとのWeb版への移行０円キャンペーンのチラシがはいっていたので、調査。 eKeihiの駅すぱあとはeZSoft版のCloud駅すぱあとであり、これに移行すると年間保守料が少し安くなることが判明。またCloud版のほうが機能が豊富であり、かつ１月に何度かあるデータ更新がCloudの駅すぱあとを使用するので更新の手間がいらない。ただ、アカウントメニューにある駅すぱあと単独起動ができなくなるがほとんど使用していないので問題ないであろう。 オンプレミスのeKeihiは現在http通信で運用しているので、これをhttps通信にするためにはSSL証明書が必要。これはWindowsの自己証明は不可のようだ。 ホームページのWebサーバー用のSSL証明書がマルチドメインで取得しているのでこれが使えることがわかった。SSL証明書のバインドを自分で行えば移行できるようだ。 eKeihiのURLが変更されるので、要相談。

 取引先へのメールが受信ではなく送信ができない事案発生！ ログを確認すると、450 4.7.1 でRejectされているようだ。 どうも送信メールサーバー名が設定していると思っていたサーバー名でなく、実際のサーバー名が表示されているようだ。これだとDNSの逆引きで迷惑メールと相手に判定されているような気がする。 Dominoサーバーのサーバー文書を確認、基本タグの「完全なインターネットホスト名」これが実際のサーバー名が指定されていた。今まで問題にならなかったが、昨今の迷惑メール対策で設定ミスが発覚。。。 サーバー文書を変更して、タスクでサービスの再起動を設定。 明日、また確認しよう。

 Trend Micro Deep Security でアラートの消去できないパターン発生。サポートに問い合わせた結果を記録。 アラート： Linux/Unix - SSH authorized_keys file modified - non-root users (ATT&CKT1021.004, T1098.004, T1563.001) こちらの監視項目は、SSHにパスワードなしでログインする際のauthorized_keysファイルを監視するルールとなり、警告は監視ユーザの定義がされていないことによるものだそうだ。 対処としては、以下の手順で監視ユーザの事前定義の設定。 ①監視コンソールの【コンピュータ】タブより、対象サーバをダブルクリック。 ②詳細画面内の【変更監視】→【割り当て/割り当て解除】をクリック。 ③変更監視ルール画面より、以下項目を検索してルール名をダブルクリック。 Linux/Unix - SSH authorized_keys file modified - non-root users (ATT&CKT1021.004, T1098.004, T1563.001) ④詳細画面内の【設定】タブに遷移し、 設定オプション内【継承」に入っているチェックを外し、「*」を入力。 ⑤変更監視項目内【推奨設定の検索】を実施。 仕組みは理解できていないが、ひとつのサーバーで処理をするとほかにも伝播したようだ。 念のため、すべてのサーバーに同処理を行う。 アラートも自動消去された。