TeraTerm の SSH SCP で「fopen: 3」エラー

　TeraTerm の SSH SCP（SSH を使ったファイル転送）で、いつも…というわけではないが、時々（現在二回目）嵌って抜け出せなくなるので、自戒を込めた備忘録ということで。

　SSH SCP のダアログで、以下のように受信しようとして嵌まる。

　結果、当然こうなる。

　答えは、「TO にファイル名の指定は不要（ディレクトリ名のみで可）」。
　TeraTerm は「TO」欄の指定をディレクトリ名と解釈するので、ファイル名を指定するとディレクトリ名として解釈してしまい（当然そんな名前のディレクトリはないので）「TTSSH: file open write error」「fopen: 3」となってしまう。

　我ながらバカ丸出しだが、これに嵌まると一頻り考えて抜け出せなくなる。
　まぁここにこうして書いておけば、三度と嵌まることはない（嵌ってもすぐ気がつく）だろう…多分。

本人へ確認のない「誕生日」開示について

　「誕生日」を、本人への確認なくカジュアルに開示する認識、なんとかならんものか。
　「面白みのない奴」と思われても、これは常々思う。

　世間一般では、「生年月日」は本人認証の一要素にされている。
　それの是非についても言いたいことはあるのだが、それはそれでそうなってしまっているのだからしようがない。であるのだから、「誕生日」の開示（あまつさえ本人への確認なく）には慎重であるべきだ。

　「生年月日」は個人情報だが、「誕生日」は単なる「月日」で自ずから個人情報ではない…という意見を開陳しているページも見かけるが、それは詭弁だろ。
　なんとなれば、「誕生日」…つまり「月日」が判明すれば「年」の類推はそれほど難しくない。例えば、外見等から「40歳前後」くらいが判れば、数年の幅を持たせば正解にヒットする。数年…つまり、たったの数パターンだ。
　対して「誕生日」のパターンは 365パターンだ。自ずから重要性は明らかだろう。

　念の為、誕生日を知人縁者へ教える（場合によっては SNS で公開する）ことを論難しているのではなく、「本人への確認なくカジュアルに開示する」ことについて述べている。
　会社で社員間の親睦のために開示するというのも良いだろうが（それはそれで大切で意義あることだが）、当然のように行うのではなく、先立って本人への確認はするべきではないか。

お名前.com の「ドメインプロテクション」機能を調べてズッコケた

　Google Domains へ引越してお名前.com とは手を切ったので、後は野となれ～なんだが、気になってちらっと調べてみた。

　今更ではあるが、レジストラ（ドメイン管理）サービスなんていうのは、基幹中の基幹であるのは言うまでもない。レジストラのアカウントが奪取されたら、whois 書換放題 ＝ ドメインハイジャックし放題な訳で、上のレイヤでセキュリティをいくら固めていても全部ひっくり返されてしまう。
　なので、レジストラのアカウントというのは、最重要アカウントとも言える。

　なのだが、お名前.com のアカウントは、未だ二要素認証に未対応。
　有り得ないなぁ…と思っていたが、お名前.com も流石にどうかと思ったのか「ドメインプロテクション」なる機能を考案していた。

ドメインプロテクション - お名前.com

　ふむふむ、ドメインに対してクリティカルな変更が加えられた場合、登録したメールアドレス宛に承認要求のメールが飛ぶという仕組みか。
　なんとも泥臭い方法だし、そもそもログイン認証がザルだというのは如何なものか。まぁ、とはいえ一歩前進か…と思って読んでいたら…

「1ドメイン980円（税抜）／年」

　はい？
　有料サービスなんかいっ！！

　ほんともうズッコケたよ。
　当然備えていて然るべき機能（しかも不完全な）で金取るのかね。
　しかも、ドメイン維持の本体費用に匹敵するような金額を。

　最近まで（不承不承とはいえ）利用していた身が何をか言わんやだが…お名前.com、今や「情弱向けレジストラ」の様相を呈しておりますな。

グループポリシーへ「Encryption Oracle Remediation（暗号化オラクルの修復）」の追加方法

2018 年 5 月の更新プログラム適用によるリモート デスクトップ接続への影響 - Microsoft Technet

　2018年 5月の Windows Update で、リモートデスクトップ（RDP）周りのセキュリティ強化があって、接続できないサーバーが続出。
　まぁ、サーバーも Windows Update を適用すれば問題ない話なんだが、現実問題そうそう簡単にできるものではない。

　というわけで、姑息（本来の意味）な解決方法を取ることにした。
　グループポリシーで以下の設定をクライアント側へ施せば（当然セキュリティレベルは「脆弱」になるものの）、取り敢えず接続できるようになる。

----------引用ココから
[コンピューターの構成]
-> [管理用テンプレート]
-> [システム]
-> [資格情報の委任]

ポリシー名 : Encryption Oracle Remediation (暗号化オラクルの修復)
設定 : Vulnerable (脆弱)
----------引用ココまで

　しかし、このポリシー項目、一覧に表示されないのだ。
　ローカルグループポリシーであれば、問題の Update を適用すれば追加される（そりゃ問題の Update が未適用なら不要な項目なんだから）。しかし、ActiveDirectory 側のグループポリシーにはどうやって追加すれば…？

　はい、以下のグループポリシーテンプレートを ActiveDirectory 側へ追加すれば OK だ。

Administrative Templates (.admx) for Windows 10 April 2018 Update (1803) - Microsoft ダウンロードセンター

　グループポリシーテンプレートの利用方法は以下。
　最初に書かれている方法より、後に書かれている「セントラルストア（中央ストア）」を使う方法のほうが楽かな。

Windows 10でグループポリシー設定を利用するには - @IT

　これで ActiveDirectory 側のグループポリシーにも追加されて、そちらで一括適用。
　メデタシ、メデタシ。

　………本当に「メデタシ」なのは、サーバー側へ最新の Update を適用してからなんだが。

Microsoft Excel が決定的に劣る点

　Google スプレッドシートと比較して、Microsoft Excel が決定的に劣る点。
　長年のウィークポイントであった同時編集については、Office 365 でほぼ挽回しているようだし、今回ツッコむのはその点ではない。

　ズバリ、Microsoft Excel は「行列の削除ができない」。

　なんのこっちゃ、という人もいらっしゃるやもしれないが、試しに Microsoft Excel で「空白のブック」（新規ワークブック）を開いてもらいたい。
　そして、ワークシートで最大行列のセル（一番右下のセル）を選択する。[Ctrl]+[↓] と [Ctrl]+[→] でキー操作すると早い。行は「1048576」、列は「XFD」になっているはずだ。
　その上で、適当な行や列を「削除」してみる。行や列を選択して、右クリックのプルダウンメニューから [削除] を選択する。しかし、表示されている最大行列のラベルは「1048576」と「XFD」のままだ。
　言うなれば、選択した行列の削除はされているのだが、域外から削除されたのと同数の行列が追加されている。つまり、ワークシートの行列数は増減しない。
　これが「行列の削除ができない」の意味。

　Google スプレッドシートの場合は、削除すれば普通にその分行列は減る。
　実に単純だ。

　一見どうということもない違いではあるが、さに非ず。Microsoft Excel はワークシートの全体像を明示できないのだ。
　見えている範囲の表や数値で全てかと思っていたら、極端な話 XFD1048576 のセルにデータが入っているかもしれない。それは実際に調べてみないと判らない。
　確かに [Ctrl]+[End] で「最後のセル（右端の使用されている列の、最も下の使用されている行のセル）」へ移動できるので、それで確認はできるが、そうやって意図的に調べないと判らない。
　削除できないのなら非表示にするという手もあるが、「見えていないだけで実体としては残っている」というのは混乱の種になるだけだ。

　対して Google スプレッドシートの場合、不要な行列をバッサリ後腐れなく削除しておけば、シートの全体像は一目瞭然になる。
　実に明瞭だ。

　Microsoft Excel はバージョンを重ねても、この辺りの仕様が改善される気配はない。
　おそらく高邁なる設計思想に基いているからなんだろうが、それだけにこれからも「決定的に劣る点」として残り続けるだろう。

ソフトバンクのキャリアメール、運用ポリシー変更した？

　ソフトバンクのキャリアメール（ @softbank.ne.jp ）、SMTP Server の運用ポリシー変更したのかな。
　先週金曜日（2018/02/16）から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。

　しっかし、キャリアメールは昔から頭痛の種なんだよな。
　早く絶滅せんものか。

　今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
　SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな（実際利用者は右肩下がりらしいので喜ばしいこと）。

e-Tax のインフラは Akamai

　e-Tax って、Akamai（※）のネットワーク使って展開してるんだ。
　今更ながら、「www.e-tax.nta.go.jp」を正引＆逆引して気が付いた。

　さらにフロントエンドのみならず、バックエンド側も Akamai のネットワークでかためている模様。

※：
アカマイ・テクノロジーズ - Wikipedia
世界最大手の CDN業者。本社米国。

　何だかなぁ。これは一納税者として納得いかん。
　国家事業なんだから、安全保障上からも国内産業育成からも、国内の業者に任せるべきだろ。
　余分に金を積んででも、IIJ 辺りにやらせて欲しい。

G Suite グループでは配信不能レポートは配送できない

　G Suite（旧 Google Apps）のグループ（ML、メーリングリスト）では、SMTP Server からの配信不能レポート（エラーメール）は配送できない。

Google グループに関するよくある質問（管理者向け） - G Suite 管理者 ヘルプ
----------引用ココから
グループに送信できないメールの種類はありますか？

「返送メッセージ」とも呼ばれる配信不能レポート（NDR）をグループに送信または転送することはできません。NDR に似ているメッセージも、送信や転送はできません。
----------引用ココまで

　この仕様、つい忘れて毎度「？？？」となってしまう。
　単に「できません」としか書かれていないが、具体的な動きとしては配信不能レポートを dsn=2.0.0 で受取った上で、何処へ何も残すことなく（グループの管理画面にも痕跡を残さず）暗黙の内に破棄してしまう。

　グループアドレスを代表にして、それを使ってチームで顧客対応をしたりする場合。つまり、各メンバはグループアドレスを From にして顧客へメール送信し、顧客にはグループアドレスへ返信してもらう（自動的にグループメンバでシェア）という運用の場合、問題が出てくる。
　顧客のアドレスを間違って入力した場合（またはアドレスが既に存在しない場合）、普通は User Unknown で配信不能レポートが戻ってくるので直ちに気がつけるのだが、この場合 G Suite のグループは配信不能レポートを飲み込んでしまうので、それに気が付けない。これは困る。

　回避方法としては、グループを使うのではなく G Suite の実アカウントを使って転送設定するか、「デフォルトの転送の設定」を使って転送設定するか…辺りか。
　前者はユーザレベルでもメンテナンス可能（メンバの追加／削除が可能）だが、実アカウントを使う関係上コスト増になる。もちろん個別にアカウントを用意せずとも、個人アカウントで併用するという手もあるが…さらに管理が面倒になる。
　後者はメンテナンスが管理者に限られる上、クリティカルな作業になってしまう（下手するとドメイン全体のメール配送に悪影響が及ぶ）。メンバの追加／削除ごときで、毎度々々そんなところをいじってられない。
　どちらの方法にしても、非常に整備性が悪い。

　G Suite というのは優秀なサービスなんだが、こういう割り切って使わなくてはいけない仕様が所々ある。
　まぁ、何でもトレードオフということなんだろうが…。

RAIDストレージが壊れた & RAID1 の分散読込による高速化

　自宅で使っていた RAIDストレージが、壊れてアクセスできなくなった。
　とは言っても、RAID を構成している物理ドライブが壊れたのではなく、壊れたのは筐体側というあるあるパターン。つまり、RAIDストレージは一撃にして使用不能。
　ドライブは多重化できても、筐体（RAIDコントローラ）はシングルポイントにならざるを得ない。あまつさえ使っていた筐体は NAS ではなく USB 接続の「HDDケース」で、オモチャみたいな RAID機能だった。こうなったのも、まぁ宜なるかな。

　ただ、幸い RAID1（ミラーリング）で使っていたので、構成ドライブの片方を引抜いて USBアダプタで直結すれば、何の問題もなくそのまま使える（もちろん冗長性は失われているが）。
　RAID5 や RAID6、それに RAID10 ではこうはいかないわけで、RAID1 の単純さ故の利点（※）。

※：もっとも、それ故にドライブの廃棄時や、修理交換時には（他の RAID 以上に）気を使うんだが…。

　かくなる次第で現在、後釜にすべき製品を選定中。
　どれを選んでも大差なかろうから適当に選んでいいかと思いつつも、できれば RAID1 の分散読込に対応している製品はないかと物色している…のだが、その辺りに言及している品が見つからない。
　当今では RAID1 の分散読込ぐらい当たり前に対応しているだろうと思い、かつては今回壊れた製品を購入したのだが、読込では片一方のアクセスランプしか点灯せずにガッカリしたという事がある。

　分散読込に対応しているような「気の利いた」製品は、昔同様やはり相応に本格的なもの（お高価い）である必要があるんだろうな。


追記：
　軽く検索してみたのだが、世の中には「RAID1 の分散読込による高速化」というものを頑なに理解しない人がいるらしい。前世紀からの常識と言わずとも（実際 1990年代で普通に言及されていた）、2台のドライブへどの様にデータが保存されているのか考えたら、分散読込が可能なことは（技術的な手間や是非は置くとして）自明だと思うのだが。
例： 『RAID1構築での読み込みドライブは１つ？』 - 価格.com

FireFox のプロキシ設定でハマリかけた

　FireFox のプロキシ設定でハマリかけたので。
　なお、これは Windows 10 Fall Creators Update + FireFox 58.0.1 の話。

　さて、順を追って書いていくのも面倒なので、引掛けポイントを列挙する。

1. FireFox は DHCP による WPAD に未対応
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
3. Microsoft DNS Service には「DNS 禁止リスト」がある

1. FireFox は DHCP による WPAD に未対応

　プロキシ設定の配布方法には色々な方法があり、その中で一番自動化された方法が WPAD による配布。
　さらに、WPAD による配布にも二通りあり、DHCP で配布する方法と、DNS で配布する方法がある。

WebブラウザのProxy設定を行うための4つの方法（WPADのススメ） - @IT

　で、FireFox は DHCP による配布には対応していないというわけ。なので、WPAD を使おうとすると、勢い DNS で配布する必要がある。
　以下のページで主要ブラウザについてまとめられているが、FireFox のそれは Windows に於いて例外的な挙動。

Browser Support - FindProxyForURL

　まぁこういう仕様になっている理由は、概ね類推できるが…足並み揃えて欲しいよなぁ。

2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない

　FireFox のプロキシ設定は、デフォルトで [システムのプロキシ設定を利用する] になっている。
　そうなっているのは普通に考えるならベターな選択だとは思うが、残念ながらシステム設定を利用してくれない場合がある。

システム（IE）のプロキシ設定：  [設定を自動的に検出する]
FireFox のプロキシ設定： [システムのプロキシ設定を利用する]

　以上の場合（なお、これが OS & FireFox のデフォルト状態）、当然 IE 側は WPAD を検索して見つかればその設定を使ってくれる。FireFox も WPAD を検索してくれ…そうなものだが、してくれない。
　どうも「[設定を自動的に検出する] というシステム設定」は、利用してくれないようだ。なので FireFox で WPAD を利用しようとすると、デフォルトから [このネットワークのプロキシ設定を自動検出する] へ変更しないといけない。

　これが意味するところ、プロキシが必要な環境において、FireFox はどう頑張ってもデフォルトで動くようにできないということ。もちろん、FireFox の設定ファイルを自動配布するという手もあるが、本来はネットワーク側の設定だけで解決する話が、わざわざ別途そこまで手をかけてやる必要がある。
　これは、心底ガックリ仕様。

　なお、念のため確認したところ、macOS High Sierra + FireFox 58.0.1 では再現しない。つまり [システムのプロキシ設定を利用する] でちゃんとシステム設定に従って WPAD を検索してくれる。
　…これ、Windows版 FireFox の不具合なんじゃねーの？

3. Microsoft DNS Service には「DNS 禁止リスト」がある

　これは FireFox の問題ではないが、関連してハマリかけたので。

DNS 禁止リストからの WPAD の削除 - Microsoft

　セキュリティ上の問題で、「wpad」は「DNS 禁止リスト」に入れられている。なので普通に設定しただけでは、問い合わせに答えてくれない。
　これは「DNS 禁止リスト」を更新すれば解決。

動的更新で「wpad」レコードを登録されたら…と考えると当然の処置だが、それならそれで設定時に「禁止リストに入っとるで」と警告を出すとかして欲しいよなという気も。

----------

Afterfollow 2018/02/13

　「2」の現象、Windows XP + FireFox 47.0.2 なんていう化石環境でも再現する。
　どうも「不具合」というわけではなく、Windows版 FireFox の「仕様」である模様。
　「不具合」であれば、新バージョンで改善するという希望も持てたんだが…。

DELL PC で警告イベント「イベントID: 19」が大量出力

　DELL のデスクトップPC（OptiPlex 9020）を、Windows 10 Fall Creators Update でクリーンインストールした直後、OS のシステムログへ以下の警告イベントが大量に吐出されていた。

----------イベントログ 引用ココから
ログの名前:         System
ソース:           Microsoft-Windows-WHEA-Logger
日付:         
イベント ID:       19
タスクのカテゴリ:      なし
レベル:           警告
キーワード:       
ユーザー:          LOCAL SERVICE
コンピューター:     
説明:
修正されたハードウェア エラーが発生しました。

コンポーネントによる報告: プロセッサ コア
エラー ソース: 修正されたコンピューター チェック
エラーの種類: 内部パリティ エラー
プロセッサ APIC ID:
----------イベントログ 引用ココまで

　なんぞ？と思い、BIOSレベル／OSレベルで診断プログラムを実行するも、全て異常なし。
　Webで調べると「イベントID: 19」は、CPU交換したら or 電圧上げたら or 電源ユニット交換したら治まったという情報があったので、何らかの異常が検知されるの（機材の故障）を期待したんだが…。

　診断プログラムで異常が出ない以上ちょっと気が引けたが、その為の費用は出しているんだからとサポートへ問合せを入れた（急がないのでメールで）。

　問合せを入れた直後ふと気になって、BIOS は最新だよな（先日バージョンアップしたばかりだし）と念の為確認した所…なにかおかしい。先日適用した最新バージョン（A21）がサポートサイトから…消えている！？
　まさに「あ…（察し）」。

　そう言われてみれば、A21 では CPU関連の脆弱性（Meltdown & Spectre）対策も含まれてたな。
　その線からサポート情報を探ると、簡単に出てきた。

マイクロプロセッサーのサイドチャネル脆弱性（CVE-2017-5715、CVE-2017-5753、CVE-2017-5754）: デル製品への影響 - DELL
----------引用ココから
更新日: 2018年1月22日

インテルは、スペクター（バリアント2）、CVE-2017-5715対応のためにリリースされたBIOSアップデートに含まれているマイクロコードによる「再起動の問題」に関する新たなガイダンスを公表しました。デルでは、すべてのお客様は、現時点ではスペクター（バリアント2）脆弱性のためのBIOSアップデートを導入しないようにすることを推奨いたします。デルは影響のあるBIOSアップデートをWebから削除中であり、影響を受けるプラットフォームに対する新たなBIOSのアップデートはサスペンドになっています。

すでにBIOSアップデートの適用を行ってしまった場合は、新たな情報およびBIOSのアップデートリリースが入手できるまでお待ちください。現時点では、それ以外のいかなるアクションも行わないでください。引き続きアップデートを過去にさかのぼってご確認ください。
----------引用ココまで

　今回の警告イベント大量出力は、これに関連する余波ではないかと類推できるんだが「いかなるアクションも行わないでください」とのことだから、軽挙妄動して旧バージョン（A20）へ戻すことなく、一旦サポートからの回答を待つことにする。
　恐らくサポートは情報を掴んでいるはずなので、適切にアドバイスしてくれるだろう。

----------

Afterfollow 2018/01/29

　今日、サポートからの回答があった。
　予想通り「Meltdown & Spectre 対策の副作用」だった模様。

　もっとも、自分が掴んでいた以上に追加する情報はなく、上記ページの URL を案内してくれた上で「新しい BIOS のリリースを待ってくれ」とのこと。

　まぁやっちまった（BIOS をアップデートしてしまった）ものは仕方ないので、アドバイス通り新しい BIOS のリリースを待つことにする。
　幸いなことに目に見えた障害は発生していないことだし。

Windows Server DHCP の引越し（Export & Import）コマンド

　「Windows Server 2003 の～」という書出しだが、2008 R2 → 2016 の引越しでもちゃんと動いてくれた。更に言えば、ページの最終更新日は「2017/01/08」。

Netsh ユーティリティを使用して DHCP スコープをエクスポートまたはインポートする方法 - Microsoft サポート

----------Export方法 ココから
C:\>netsh
netsh>dhcp server \\servername
netsh dhcp server>export c:\temp\dhcpdb all

コマンドを正しく完了しました。
netsh dhcp server>
----------Export方法 ココまで

----------Import方法 ココから
C:\>netsh
netsh>dhcp server \\servername
netsh dhcp server>import c:\temp\dhcpdb all

コマンドを正しく完了しました。
netsh dhcp server>
----------Import方法 ココまで

　「\\servername」のところは Export元／Import先のサーバ名に置換える。

　引越しに際して、予約設定（MAC Address と IP Address の紐付け設定）がアホほどあるので、さてどうしたものかと考えていたら、ちゃんとコマンドが用意されていた。まぁ何を今更な発見で、何年 Windows Server を管理しているんだという話だが…。
　なお、Export されるファイルはバイナリなので、これをテキストエディタで編集して…という技は不可（残念

Google Chrome 初期化方法

　Google Chrome の調子が悪い時は、小細工せずにコレで一発解決。
　コレでダメなら、Chrome 自体の再インストールしか無いんだが、そこまでの経験は今のところない。

　さて、一発解決の方法。
　Chrome を終了（常駐も含め）させた上で、以下のフォルダ（ユーザデータのフォルダ）をリネームしてしまう。
　なお、常駐を含めて終了させても、プロセスが残ってファイルを掴んでいてリネームに失敗する場合がある。その場合は再起動させた上で実施。

%LOCALAPPDATA%\Google\Chrome\User Data

　リネームしてから Chrome を起動すると、ユーザデータが見つからないので新規に作ってくれる。
　これで大概の問題は解決する。

　ただ、この方法には前提があって、Google アカウントへリンクさせていないと（当然だが）すべての設定が空っぽになってしまう。反対に言えば、Google アカウントへリンクさせているのなら、アカウントへログインすれば一瞬で環境は復元される（復元されないのは cookie くらい）。

　なお、Chrome の設定画面に「リセット」があるが、恐らくこの方法の方が根本的処置になるんでないかな。