(IT) jcomのメールサーバーの行儀が悪い


shirao.netというドメインを20年くらい前に取得して、主にメールでつかっている。
メールサーバーも最初は当時の所属会社にひっそり置いたSunのマシンにqmailを入れて稼働を開始し、その後自宅のSun Ultra10で稼働させていたが、震災の計画停電のタイミングでawsへ移行した。いったんOCNのCloud-nに浮気をしたものの、USリージョン閉鎖に伴い再度awsに戻ってpostfix化したりして。業界の人ならわかると思うけど、自分でメールサーバーを運用するというのはもう、無駄でしかない。
メールを使うだけならGmailでええやんけ、が正解。自分のドメインも持ち込めるし。
自分でメールサーバーを運用していると、攻撃パターンとか迷惑メールのトレンドを肌で感じることができ、少なからずシゴトに活かせるので、面倒だが、好きでやってる感じかな。
実家の両親にも最初からこのドメインのアカウントを使わせていて、メーラーはOutlookを触らせず、最初はAl-Mail、最近ではThnderbirdを使わせている。

ここ一週間くらい、実家の母(84)から俺のアカウントにメールが届かないという事象が発生していた。

同じドメインで同じサーバーを使っている俺も父も何事もなく送受信できているにもかかわらず、だ。
ログを見てみると、こんな感じでrejectしてた。

予想されるストーリーはこんな感じ。
(1)Thunderbirdのアップデートか何かでshirao.netドメインのSMTPサーバーの設定が飛ぶ
(2)その後の送信時に、回線のグローバルIPからJCOM回線と想定され、SMTPサーバーにJCOMのデフォルトが設定される
(3)母から俺あてのメールはshirao.netの中で完結するのに、なぜかjcomのサーバーらしきサーバーから飛んで来る
(4)そのjcomらしきサーバーはomta0014.jcom.zaq.ne.jpという名前でくる。(0014の数字の部分はその時々で違う)
(5)omta????.jcom.zaq.ne.jpというサーバーは正引きでIPアドレスを引けない
(6)ホコリ高き(笑)我がサーバーは正引きできないサーバーからのメールを受け取らない
(7)親子の断絶が生まれる
(8)余談だが、母のお友達のjcomユーザーのメールもrejectしてるが、全部jcomが悪いからね

俺のGmailのアカウントだとメールが届くので、それを使って「ThunderbirdのSMTPサーバーの設定を確認してくれ」と伝えたが、結局どこをどう見ればいいのかわからんと言われ、俺もThundebirdユーザーじゃないので、見ないとわからんということで、クイックアシストすることに。

普通の人なら、スタート>Windowsアクセサリ>クイックアシスト、と言えば、2秒で行けると思うのだが、84歳は一筋縄ではいかない。スタートメニューがなんだ酷いことになってるらしく、Windowsアクセサリに到達できない。作戦変更して「スタートで右ボタン押して検索でkuikkuと打つ」を電話で128回叫んでようやくクイックアシストの「支援を受ける」ボタンに到達。ここまで30分。
クイックアシストで母PCの中をみたら、ThnderbirdのSMTPサーバーはやはり、jcomのデフォルトに変わっていたので、shirao.netの設定に変更。パスワードを設定するところがなかったんだが、テスト送信時に認証のパスワードを聞かれ、無事に設定終了。母PCから俺のアカウントへのメールが開通した。クイックアシストで入ったら10分で解決。昔は、千葉県北部まで足を運んでたが、このクイックアシストは便利だし、感染防止にも役立つな、これ。それにしても年寄りはなぜスタートメニューが酷いことになるんだろうか。確かに酷かったけど、そっとクイックアシストを閉じたなど。

とはいえ、正引きできないサーバーでメール送信してくるjcomのサーバー、ダメだと思うぞ。きっと、届いてないメールたくさんあると思うんだが、大手プロバイダだし、確信犯ってことなのかしら。設計間違えちゃったのかしら。

(IT) 10月1日の東証の取引停止について


今日の東証の丸一日の取引停止に関してシステム屋の観点で考えてみた。
個人的に興味があったので、ニュースサイトの記述やテレビの報道はあえて観ず、Youtubeで東証の記者会見を全編観て個人的に考えてみた。

■原因特定の速さ
朝7時のバッチ処理の失敗でアラートがあがり、その原因がストレージ装置のメモリ不良であると特定されるまでのスピードはすごいと思う。常識的に考えれば、物理的に回転しているディスク装置と違って、メモリが壊れることはまあ、想定できない。しかしその早い特定に従って9時前の段階で10月1日の丸一日の取引停止を判断したことは尊敬できる。これはソフトウエアのバグに関しては潰しきった自信があって、原因はハードウエアの障害に絞って調査したからだと勝手に想像している。

■フェイルオーバーの失敗
だいたい、テストではうまくいくけど、この手の障害発生時の自動的な復旧処理はまあ失敗する(笑)。某クラウドのデータベースSaaSのフェイルオーバーの失敗で大障害が発生し、謝り侍とクレーマーを演じた身としては、同情を禁じえない。なぜかDBのフェイルオーバーは失敗するし、RAID構成のディスクは復旧できないし、バックアップデータはリストアできなかったりする。なんでそうなるか?マーフィーに聞いてくれとしかいいようがないが、謝るのはオレ(たち)。

■経営サイドの英断
今回の丸一日の取引停止が与える経済的損失とか影響はオレには関係ないので、ここを論じる考えは全くないのだが、朝7時の障害発生を受け、その重みとリスクを勘案し、早いタイミングで一日取引をやめると判断した経営サイドは素晴らしいと思う。多くの経営サイド(事業推進サイド)は1秒でも早い回復を要請し、多少のリスクを飲み込んで事業の再開を優先するが、今回の障害において東証の経営サイドはシステム上のリスクを理解し、損害や批難を顧みずサービス停止の判断をしたことは、まさに英断と言えると思う。

■技術責任者の内容理解
記者会見で社長の右隣にいた技術責任者はメモをほぼ見ず、自分の理解を自分の言葉で話し、質問に答えていた。これでこそ責任者だと感じた。尊敬している。10月2日の稼働に関しては有人監視にて対応ということだったが、人がいてもダメなモンはダメで再発はするが、対応速度が早く手順が確立しているので、対応が可能ということなのかと思う。

■質疑応答での記者の質問
「私はシステム的なことはよくわからないのですが」と前置きをして、ストレージ装置のメモリがどういう役割をしているものかを勘違いした質問をする記者のなんと多いことか。チコちゃんに叱られて来い。一日の停止の経済的な損失ではなく、障害を抱えたままでの稼働による損失とのトレードオフを考えたことがあるのかとマジで問いたい。記者会見の全編を観た後で、いくつかのニュース番組の扱いを確認したが、東証の真意が伝わるものとは到底思えなかった。しかし、メディアが曲解し、切り取って報道することを前提に、真摯に記者会見において発言される東証の姿勢については、評価したい(上から御免)。

■まとめ
「デジタル社会」とは、システム障害によって、リアルな生活に影響が出ることと強く感じた。
今回は証券取引が一日止まった「だけ」だけど、将来、システム障害があって、電気が何日も来ないとか水道が止まるとか生活インフラの不安定さにつながるリスクはあるわけで。それをどこまでリスクを減らせるか、といのがシステム設計者の使命(システム開発者ではないことが重要)。東証の社長が言っていた通り、富士通はベンダーではあるが、サービス継続の責任は東証にある、というのと同じで、システムのベンダーがどこだろうと、サービスの主体はサービス事業者であることを再認識した事象ではあった。
そして、日本の立法や行政のITリテラシーの低さの一因はテレビ新聞などのメディアのITリテラシーの低さにあると痛感した会見でもあった。

珍しくつまらないエントリーを書いてしまったw

(IT) お世話になります


「お世話になります」:これから取引をするかもしれない会社へのメールの書き出しの定型句
「お世話になっております」:既に取引のある取引先へのメールの書き出しの定型句

という違いがあると指摘され、愕然としている55歳(告白)。
主に接客業などのサービス業においては常識らしく、入社時研修で覚えるべき項目とのこと。
これまで、何の疑いもなく、取引があろうがなかろうが、「お世話になります」しか使ってなかった。みんなどうしてた?
常日頃、メールの件名がどうだ、成増がどうだとえらそうに書いてるクセに知らなかったことがあったとは誠に恥ずかしい。恥ずかしい記念に晒しておく。ああ恥ずかしい(棒)。

知らなかったくせに反論するわけではないのだが、マナー大好き日本人は勝手にいろいろなルールを設定して魔女狩りをしてきた感じがしないでもない。
社内を宛先としているメールの頭に「お疲れ様です」とつけるのも同じ。それ意味あるか?って思ってるから、つけないようにしてる。
電子メールという後発のコミュニケーションツールにおいて、レガシーなツールである「電話」で運用されていた(なんとなくやってきた)マナーをそのまま適用したのではないかと推察する。「お世話になります」も「お疲れ様です」もそもそもは電話マナーだよねえ?

さらに新しいツールであるLINEやSlackやTeamsでは「お世話になっております」も「お疲れ様です」も書かないのが主流だし、「件名」も存在しない前提でコミュニケーションが成立しているし、それでも電子メールからのシフトは進んでいる。社内だけではなく取引先とも。
だからといって新しいツールでの新しいマナーを古いツールへ適用することは、理屈はどうあれ、社会的信用のためには、避けるほうが無難であることは理解する程度に歳は取ったわけで。

そんなわけで、自分に言い聞かせるために再度書いておく。
「お世話になります」:これから取引をするかもしれない会社へのメールの書き出しの定型句
「お世話になっております」:既に取引のある取引先へのメールの書き出しの定型句

(意訳:土下座する大和田常務の顔で打っていると思ってください)

(IT) キーボードへのこだわり


先日テレビの「マツコの知らない世界」で自作キーボードの話題を取り上げていた。
キーの配列が気に入らないから自分の好きな配列のキーボードを作ることについては尊敬しているし、理解できないでもない。友人が言うには、キーボードは「馬の鞍」というらしく、PCや馬は消耗しても、キーボードや鞍はそのまま使うほどに愛着を持って使うものであるということらしい。この意見というか考え方には完全に同意。

だからオレもさぞこだわったキーボードを使っているかと言うと、そうではなくて、Appleキーボード一択。

薄さ、傾き、キータッチ、騒音、キー配置について、何も問題なく、自然に使えるキーボードがこれなので、PCがMacだろうかWindowsだろうか基本、これで過ごしている。Windowsにおいては全角/半角の切り替えとか、それはそれでいったんキーボードに目を落として確認してから押すこともあるが、これはまったく気にならない。
人によってはCTRLキーの場所が重要な人もいるようだが、キートップに書いてあるし、何の不自由もない。
Windows用の「キーがやたらと多いキーボード」の有用性がいまいち便利に思えない。「メール」ボタンってなんだ?とw

というように思えるのは、いろんな車を入れ替わり立ち代わり運転することがあったからだと思っている。
右ハンドルだったり、左ハンドルだったり。マニュアルミッションだったりオートマチックだったり。ウインカは右のレバー?左のレバー?ワイパーのスイッチはどこ?サイドブレーキって足で踏む?レバー引く?みたいなレベルで確認しつつ操作していることに比べれば、パソコンのキーボードの操作の差異なんて、本当に誤差だと思う。
言い換えると、CTRLキーの位置をきにする人は自分の車(または、自分的に標準な車)しか運転できないから、車側が合わせて!って言ってるように聞こえて違和感があるわけで。
ハードウエアの仕様に人間が合わせる事を拒否し続けるか、ハードウエアの今ある姿を認めてあげて人間の側で適応してあげることに拒否感があるかどうかの違いなのかも、とも思っている、それが人間の敗北ではなく、プロダクトの製作者へのリスペクトと信じているから。(ちょっとポエム)

(IT) Big-IPがやられたけど、仮想化してたから速攻でリカバーできた話


サーバセンターなんかで赤くて丸いf5と書かれた筐体を見たことがある人も多いはず(普通見ないかw)。

いまいる会社でもファイヤーウオールとロードバランサーで使ってるわけで。この会社の事例紹介でも取り上げてもらった。
ご存知の通り、紹介されるといろんなサービスがあっ(以下自粛)
採用したのはaws上(クラウド上)で動くVE(Virtual Edition)版ではあるものの、令和の時代にあっても、多くの企業や行政ではリアルな筐体でBig-IPを採用しているところは多い(はずだ)。
で、この日本だけではなく、世界でシェアをもつファイヤーウオールに脆弱性が発見された。
例えば、Windows10に脆弱性が見つかって攻撃されても、パソコンの中に入っている一人か二人分の個人的なデータ漏えいする可能性があるだけ(シゴト用のパソコンでサーバーへのログイン情報とかが記録されていたらその限りではないけどね)。しかし、一般的なWebサーバーは、「そいつ(ファイヤーウオール)が守ってくれるから、(一般的なことはするにしても)特別な防御をしなくてもいいよね?」という前提で、インターネットに直で出しているサーバーよりも安心感を持って設定してあるわけ。そこへもってきて、ファイヤーウオールに脆弱性があるってことは、みんなが頼りにしてたそいつに弱点があって、何ならログインされて、踏み台にされたら、壁の内側を荒らされ放題(技術的にはかなり高度な知識と経験がいるけど)になる可能性があるわけよ。もう、インフラ屋からすればオカルトそのもの(怖)。
一般的な「セキュリティ」の考え方としては、「可能性がある」時点で、「やられてしまった」と捉えて対応しないと、大変なことになる「可能性がある」ので、対応必須というのが常識なわけで。
というわけで我々も対応開始。業界的にいうと、「お祭りがはじまった」状態なわけだ。

セキュリティ上の問題で、当該のファイヤーウオールがどんな状態だったかは詳しく書けないけど、少なくともこの脆弱性をついた攻撃はゼロ回じゃなかったことだけは確かだと観測された。だって、前述の通り「この会社はf5のマシン使ってまっせー!」ってインターネット上に書いてあるんだから、ここの事例集に載ってる会社にはとりあえず攻撃してみるのが正しい「悪意のある人」の行動。
ということはもう、可能性があるわけだから、やられちまった前提で対応を開始。
とりあえず、メーカーが推奨しているようなネットワーク上の設定はすぐに実施したが、問題は機器の再構築。
オンプレでリアルの筐体を使っている会社はマシンをネットワークから外し、初期化して、ゼロからインストールして、それまで実施してきたシグネチャの適用を全部順番にしないといけない。それはそれは気の遠くなるような作業で、ベンダーさんに頼んでも何百万円もかかって何日いや何ヶ月かかるかもしれない。
しかしオレが担当しているファイヤーウオールは仮想化といって、クラウド上で構築されているので、毎日その機器の状態を「スナップショット」という形式でバックアップしている。なので、攻撃が開始された前日のスナップショットから復元することで、数時間で安全な状態に復帰できる、はずだった。スナップショットからの復帰については大きな問題はなかった。2台が並行して動いていて片方が死んでももう片方がすべてのトラフィックを捌ける設定となっており、リソース的に問題ないことも実験済だった。この機能を利用して、1台づつネットから隔離して復元してネットに復帰させれば、全体のネットワークを止めず、業務影響なく対応できるはずだった。
ところがネットワーク内の他のサーバーで数台、片方のファイヤウオールからの応答がないと動作に支障をきたす設定となってるものがあり、1台をネットから外すといくつかの部署で悲鳴があがる状況で、一台ずつ設定の確認と変更を実施したので、そこで時間がかかってしまった。
2日間にわたるお祭りも、そんな小さなトラブルもありながら、なんとか完了できた。何ヶ月もかかる可能性があるオペレーションが2日でできたし、追加のコストもなく完了したのは、スタッフやベンダーさんの緊張感を持ったオペレーションのたまものではあるわけだが、もう一つの手柄は「Big-IPをaws上のスナップショットから復元させる機能をメーカーであるf5に実現させた」男の存在だ。
VE版の出始めの頃、f5社はスナップショットからの復元は正式にサポートしていなかった。おいおい、f5さん、ソフトウエアの会社になると宣言している割には、むっちゃハード寄りというかオンプレ前提の話じゃないっすか、それ。VE版なんだからスナップショットからの復元をサポートしてくれよ、と強行に申し入れをして、結果サポートを勝ち取った。あれから3年以上経った日に、あの交渉が活きたということ。インフラを守るというのはこういうこと、と思ったよ。当時f5と直談判してくれた同僚に本当に感謝している。