  |
はてなキーワード: ログファイルとは
朝のオフィスにはいつもとは違う緊張感が漂っていた。主人公の佐藤遼太郎がオフィスに着くなり、リーダーの中島からすぐにミーティングルームに呼び出された。彼が所属するテック企業「エクスプラネット」は、日本国内でトップクラスのシェアを誇るクラウドサービスを提供している。その中でも佐藤が手掛ける基幹システムは、日々膨大なデータを扱い、企業にとってまさに生命線とも言える存在だった。
「そうだ。顧客データを管理しているクラスタ全体が応答しない状態になっている。障害発生時刻は午前3時15分。サーバーの自動復旧も失敗している。原因の特定を急いでほしい」
佐藤はすぐにノートPCを開き、障害発生時刻のログを確認するためにキーボードを叩き始めた。慌ただしく動き回る他のエンジニアたちの姿を横目に、彼は集中する。
サーバーのログファイルには、大量のリクエストエラーが記録されていた。その内容を精査する中で、奇妙な点が一つ目についた。それは、午前3時12分、つまり障害発生の3分前に発生した、大量の異常なトラフィックだ。IPアドレスは海外のもので、アクセス元は分散されていた。
「確かにトラフィックのパターンはDDoSに似ている。ただ、問題はその後だ。障害が発生する前の数秒間、アクセス元が突然ゼロになっている」
通常、DDoS攻撃は持続的に負荷を与え続けることを目的としている。しかし、このケースでは突然すべてのリクエストが消え、直後にシステムが停止しているのだ。この不自然な動きに、佐藤の直感が働いた。
「追加情報だ。サーバールームに設置されている監視カメラが、午前3時10分に一瞬だけ途切れていたらしい。そのタイミングで物理的な不正アクセスがあった可能性も出てきた」
佐藤の頭の中で複数のピースが繋がりかけていた。不自然なトラフィックの急増と消失、そして監視カメラの遮断。これが単なる偶然であるとは考えにくい。
その日の午後、佐藤たちは原因の特定を急ぐため、緊急チームを編成した。セキュリティ担当の桐生、ネットワークエンジニアの矢島、そして佐藤の三人が主要メンバーとして動くことになった。
「まず物理的なアクセスがあったかどうか確認しましょう。サーバールームの入退室記録は？」
「入退室ログには異常はない。だが、カメラが途切れたタイミングでの動きがどうも怪しい。業務時間外だから特定は難しいが…」
「つまり、何者かが監視カメラを無効化して侵入した可能性が高いですね」
矢島が口を挟む。
一方で佐藤は、引き続きシステム上の問題を追っていた。彼が注目したのは、停止直前に実行されたスクリプトだった。その中には、普段の運用では利用されない不審なコマンドが記録されていた。それは、システム全体のシャットダウンを引き起こす可能性のある致命的なもので、通常アクセス可能な範囲を超えたものだった。
「誰がこれを実行した？」
疑惑と動揺
犯人は外部の攻撃者なのか、それとも内部の関係者なのか。現時点ではどちらとも言えない。佐藤の頭をよぎるのは、最近プロジェクトを巡って対立していた別のチームの存在だ。特にリーダーの篠田は、佐藤のチームがリソースを独占していると不満を漏らしていた人物だ。
だが、同僚を疑うのは容易ではない。佐藤は一つ深呼吸し、気持ちを落ち着けると中島に言った。
「明日の朝までに、可能性のある全ての原因を洗い出します。それまで少し時間をください」
夜明け前の一歩
深夜になっても、佐藤はオフィスに残っていた。モニターの青い光が彼の顔を照らし続ける。キーボードを叩く手が少しずつ疲れを感じ始める頃、ふと別のログファイルが彼の目に留まった。それは、3か月前に削除されたはずの古いアプリケーションの実行記録だった。
「なぜこれが今、実行されている…？」
その瞬間、彼の背筋に冷たい汗が流れる。古いシステムを再起動したのは誰か。そして、その意図は何だったのか。佐藤は、次第に明らかになりつつある陰謀の存在を直感した。
———
うん。
久しぶりにガチで壊れた。
テンパってダウングレードやイメージファイル読み込みしまくって半年ぐらい時間戻したけど駄目ね。
そして気づく。
まずはログファイルを読むべきだったな、と。
まあ、読んだけど意味不明ね。
うん。
これはもう駄目だね。
うん。
cpuがwin11非対応だから1年以内に買い替えだったからまあええわ。
グラボがgtx1660superで中途半端すぎるのが悩みよ。
ちょうど来年買い換えるなら程よく型落ちね。
でもあと1年は戦えるよね。
これを思い切って切り捨ててゲーミングPC新調するか、もしくはグラボだけ抜いた構成を組むかよね。
ssdもこないだ70％ぐらいやったしまあそろそろ変えどきよね。
ゆーてそんなら保証切れないように1年ぐらいは改造せずに使いたいよねー
まぁ、パスキー(FIDO認証)でパスワードレスの流れじゃないですかね
ビックテックが下記みたいに言ってるので
MSはご希望の個人と企業にはパスワードレスを提供してるよね(大企業は本当に大丈夫か要件と運用確認した方がいい)
ショッピングサイトはAmazonくらいしかパッと思い浮かばないけど、それを追う形になるんじゃないですかね
https://forest.watch.impress.co.jp/docs/news/1540281.html
暗号化どうたらは複合ではなく出来るのは推測
システムのログファイルにパスワードが平文で記録されているとか愉快な作りではない限り、管理者もわかりません
あれだけのプレビュー捌けるエンジニアは基本的にジャガイモではないので、基本的なセキュリティ周りでどうこうは無いと思うんですけど、
えらい人がありがたい発言をたくさんしていることでも知られてますし、面接で面接者の評価に気さくな言葉を残したりしそうな、陽気なひとたちというイメージがあると思います
例えば、カスタマー対応してる時に、ユーザーからパスワードを直接聞き出し、それをメモに残しちゃったら、ハッシュ化ガーやソルト化ガーの意味ないですよね
システムを内製するので、かろうじてプログラムをかじったことのある自分が抜擢。
泣きながら障害を起こしながらも、2～3年くらい安定稼働させた。
DCに設置された連携先のサーバーが片系死んでるのお客さんに黙ってて
閉域とはいえ、サポートとっくに切れてるしやべぇからこっちも直せ、と。
設計書もソースもなかったが、バイナリからソースコードが取り出すことができた。
さぁ切替だと思った矢先、事件が起こる。
同僚の嫁に、上司が手を出そうとしたのがばれ、上司が逆切れした。
上司と一緒は嫌だなぁ、と一緒に飛ぶことに。
サーバーはここにラッキングしてあるで、取り出して持っていってください。
手順はまとめたんで、この通りやってくれれば動きますよ。と上司に伝える。
異動後の部署で仕事をこなして1年経ったか、引継ぎの子から電話。
「連携先のサーバーが障害起こしてて、どこ見たらいいですか？」と。
あれ、障害起こすと省庁に呼ばれるやつじゃない？と思いつつ
サーバーのxxにログファイル出てない？と薄い記憶を頼りに自分が作ったプログラムをおもいだす。
え？フォルダ消えたの？Dドライブの直下って何ある？ン？ピンとこないフォルダ群。
悩む。突き放すこともできるが、呑みに行ったこともあるしなぁ…。いや、会社が危ない。
一旦電話を切って空を見つつ俺考えてますよアピールしていると、ふと気になることが。
さっきのフォルダ構成ってどっかーで見たよねー？引継ぎの子に電話。
サーバーラックにxxxxってテプラの張ってあるサーバー2台、ある？無いよね？
「…えー、っとあります。」
自分が作ったサーバーはあの時のまま、DCに運ばれるのを待っていた。
引継ぎの子が見ていたのは、1年前切り替えようとした古いサーバーで、延命というか放置されていた。
古いほうの復旧方法は流石に知らないので、そりゃしらんわーとお断り。
片系壊れてて1台で動いてるサーバーをエイヤで再起動するらしい。
その後連絡は無いので、復旧はしたんだろう。会社は今も存続している。
名前のよくしられたJTC勤務だけど、
・社用PCのログがものすごく細かく取られている（ログファイルが大きくて業務に影響するくらい）
・ウイルス対策と称して複数のソフトウェアがファイルやいろんなログの監視をしている
等、情セキ部門担当責められないためにものすごく費用をかけて業務効率も犠牲にしている。
メール、チャット、WEBの閲覧ログ等も全部詳細にとっているはずだ。
さすがにパスワードは各システム統合されて一日に100回もパスワードを打つということはなくなったけれど、
（でも多いと30～40回くらいは打っていると思う。）
その割に事故は減らない。個人スマホの持ち込み管理は緩いし紙の持ち帰りも厳しくない。
情セキ部門は「そこは自分たちが責めを負うところではないので」と考えているのだろう。典型的なJTCクソサラリーマン仕草だ。
無料WEBで調べものをする機会は結構ある。そのときに、WEBページを100ページ閲覧したとき、
読みたい、意味のあるテキストはせいぜい数百キロバイトだ。でも実際のトラフィックは数百メガバイト、正味に欲しいデータ量の1000倍を
発生させてしまう。（正確にはもうちょっと小さいだろうが）無駄な広告、バナー、広告動画プレビューみたいなものを一緒にダウンロードするせいだ。広告動画プレビューみたいなものは画面を占有し、注意も占有し、業務効率を下げる。なので広告ブロッカー等でオフにしたい。
しかし、未承認ソフトウェアはセキュリティの懸念があり使うなということでEDGEでBINGを素で使えと言われ滅茶苦茶能率が悪い。
実際の必要なデータの1000倍のトラフィックが社内LANに暗号化されて流れているのを無駄と思わないのであろうか。
「そこは自分たちが責めを負うところではないので」と考えているのだろうな。
PC・スマホ・タブレット等のIT機器のヘルプ対応をしているけど、このうち対応が最も面倒なのがLinux。
Windowsやmacよりも件数はかなり少ない代わりに、対応の難易度の高さは飛び抜けている。
それもうオンサイト対応じゃなきゃ解決できねーよみたいな内容が極端に多い。
どういう使い方で、どんなソフトウェアをどのように入れたかにより、OSの奥深くにある基本的な設定が書き換わるケースもあるし、もちろんディストリビューションやバージョンごとの違いもあるしで、
設定ファイルの修正方法やコマンドを送ったくらいでは解決せず、挙げ句
「このコマンドを実行してください」
というやりとりが延々続くだけになり、手に負えなくなってサポート打ち切りになるケースがほとんど。
というかサーバじゃなくデスクトップで使っているなら、そしてそんなとこまでこっちにやらせるなら今すぐフォーマットしてWindows入れろやボケ！！！
と言ってやりたくなる。
なんでこう、Linuxのトラブルはどいつもこいつもやたらややこしいんだか。
正直Linuxのヘルプ対応をするたび、Linuxがどんどん嫌いになっていく。
(追記)
サポートってどんなサポート？という質問があったけど、本当にごく普通のクライアントPCのトラブル対応を、いわゆる情シスのスタッフとしてやっている。
ちな会社は社員数1万人くらいで、自分はそこの情シスの中の、本社の社員のIT機器をサポートするチームのメンバー。
とはいえ対応時に見ているのは社員のPCだけじゃなく、場合によってはその社員が接続した際のDHCPやDNS、FWのログはもちろん、L2・L3スイッチやRADIUSだって見に行く。
それでもトラブルの原因がわからないときがあるので、ネットワークのチームやサーバのチームに相談することもしょっちゅう。
なお自分はもともと、開発・構築・運用と使い回されてきたタイプで、開発一つ取ってもWindowsアプリにiPadアプリにWeb系にとこなしてきた。
あとデスクトップLinuxは大学いた頃に慣れ親しんでいた(レポートや論文を書くくらいには使っていた)。
で、そんな君みたいな人を待っていたんだ！と言われ引き抜かれたのが今の仕事というわけ。
ただLinuxのサポートにここまで手こずるのは想定外だったわ。
やはり専門知識という意味ではLPICくらいは取ったほうがいいのか？と思っていたり。
(追追記)
ウチの会社でデスクトップLinuxを使っているのは(macもだけど)主にR＆D部門と、そこから転属or昇進した人達。
(一方でバックオフィス系は、サポートが最も楽なリース契約のWindowsPCだったりする)
このうち問い合わせてくるのは、大体が
のどちらかで、このうち後者については部門のガバナンスどうなってんだと思わなくもない。
「それもう試した」
→どこまで何を確認したか要点だけでも教えてくださいよ…このやり取り、普通に時間の無駄ですよね？
「ありませんでした」
→「ありませんでした」じゃねえ探すんだよ！ログがなきゃ原因特定できないんだが？そんなこともわからないでLinux使ってるのかよ…。
スーパーコンピュータシステムのファイル消失のお詫び
2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムのストレージをバックアップするプログラム(日本ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データを意図せず削除する事故が発生しました.
皆さまに大変なご迷惑をおかけすることになり,深くお詫び申し上げます.
今後,再びこのような事態の生じることのないよう再発防止に取り組む所存ですので,ご理解をいただきますよう,どうぞよろしくお願いいたします.
・ファイル削除期間:2021年12月14日 17時32分 ～ 2021年12月16日 12時43分
・消失対象ファイル:2021年12月3日 17時32分以降,更新がなかったファイル
・影響グループ数:14グループ (うち,4グループはバックアップによる復元不可)
http://www.iimc.kyoto-u.ac.jp/ja/whatsnew/trouble/detail/211216056978.html
スーパーコンピュータシステムの納入会社である日本ヒューレット・パッカード合同会社によるバックアッププログラムの機能改修において,不用意なプログラムの修正とその適用手順に問題があったことで,本来は不要になった過去のバックアップログファイルを削除する処理が,/LARGE0 ディレクトリ配下のファイル群を削除してしまう処理として誤動作しました.
日本ヒューレット・パッカード合同会社から提出された報告書を掲載します.
Lustreファイルシステムのファイル消失について (日本ヒューレット・パッカード合同会社)
今後の取り組み
現在バックアップ処理を停止しておりますが,プログラムの問題を改善し,確実に再発しない対策をした上で1月末までにはバックアップを再開する予定です.
ファイル消失後にバックアップが実行されてしまった領域のファイルの復元ができない状況となったことから,将来的にはこれまでのミラーリングによるバックアップだけでなく,1世代分の増分バックアップを残す等の機能強化を検討いたします.機能面だけでなく,再発防止に向けた運用管理についても改善に取り組みます.
一方で,機器故障や災害等によるファイル消失の可能性も含めて完全な対策は困難であるため,利用者の皆様におかれましても,重要ファイルについては別システムへのバックアップをお願い致します.
これは楽天モバイルアドベントカレンダーの出遅れ記事です。嘘です。すいません。
インディアンスの楽天モバイルネタ最高だったのでこの記事を書きました。
1プランでわかりやすい料金体系、最低金額は無料、契約して1年間無料というすごい携帯キャリアです。
私は今年の3月から使っており、その品質には概ね満足していました。ところが11月中頃（曖昧）から楽天モバイルの圏外が頻発するようになりました。
ローミング終了に伴い一部エリアでは使えなくなるかもという話は知っていましたが、私がいるのは都内の3線利用できる駅前エリアで今ままでもパートナー回線を使ったことがありません。
おかしいなーと思いつつちゃんとログを取ろうと思い、楽天モバイル端末のWiFiアクセスポイントをONにして手元のノートPCから疎通確認をしてログをとることに。
楽天モバイルのDNSが落ちたことはあった時はDNS設定いじればどうにかなったけど、そもそも圏外はどうしようもありません。
crontabもないし、shじゃないし、tail,awk,uniqもないし面倒でした。
5分に一回 1.1.1.1 にpingを飛ばしてその結果をログに残しました。
以下はbatで書いた処理
@echo off ping -n 1 1.1.1.1 | findstr /i "TTL" > nul if %ERRORLEVEL% equ 0 ( set ret=success ) else ( set ret=failure ) echo %date% %time% %ret% >> %~dp0check_net.log
-- tail -3 相当のps type .92;check_net.log | select -last 3 2021/12/27 22:20:02.44 success 2021/12/27 22:25:06.00 failure 2021/12/27 22:30:05.99 failure -- awk '{print $1, ":", $3}' | uniq -c 相当のps type .92;check_net.log | %{$tmp=($_.toString() -split("92;s+"));echo ($tmp[0] + ":" +$tmp[2])} | group -NoElement Count Name ----- ---- 143 2021/12/19:success 6 2021/12/19:failure 208 2021/12/20:success 81 2021/12/20:failure 279 2021/12/21:success 9 2021/12/21:failure 221 2021/12/22:success 67 2021/12/22:failure 101 2021/12/23:failure 188 2021/12/23:success 277 2021/12/24:success 12 2021/12/24:failure 144 2021/12/25:success 69 2021/12/25:failure 287 2021/12/26:success 2 2021/12/26:failure 43 2021/12/27:failure 225 2021/12/27:success -- 時間ごと type .92;check_net.log | sls failure | %{echo $_.toString().Substring(11,2)} | group -NoElement | sort Name Count Name ----- ---- 21 0 17 1 19 2 20 3 40 4 47 5 42 6 41 7 21 8 9 9 17 10 14 14 18 15 8 16 23 17 14 18 6 19 1 20 6 21 7 22 5 23
ログが不十分なのは途中でログファイル消しちゃったのと、ノートPCを閉じちゃってタスクスケジューラが止まってたタイミングがあるため
途中まで `findstr /i "TTL"` がなかったのでsuccessだけど実際は疎通できてないものがあります(pingの宛先ホストに到達できませんはsuccess扱いだった)
12/23がひどい。1日の35%繋がらない。「日本のスマホ代は高すぎる」けど繋がらないんじゃ意味ないんよ。
11~13時台は落ちてない。逆に何故。
5分に一回の計測なのでたまたまそのタイミングだけ疎通したりしなかったりってのはあるけど、その割合は落ち具合の体感と一致します。
テザリング利用では1日10GBの制限があるらしいですが、制限には引っかかっていません。
今も利用しているのは無料期間中なのと、楽天モバイル回線はYoutubeとかネットサーフィンとか止まっても許せる範囲で使っているからです。
これをメイン回線にしてたら緊急の連絡とか取れないだろうし、だいぶ困りそう。
書き込もうとしたけど、楽天モバイル回線は圏外で書き込めないので別の回線で書き込んでます。
RSRQは-15でした、どいひー
10月28日、女性アイドルグループ・乃木坂46のメンバーである白石麻衣の卒業コンサートが無観客の配信ライブとして行われたが、その際のRakuten TVのトラブルについて書く。
・特典付きチケット(5000円+手数料）：Rakuten TVのみ
・一般チケット（3500円＋手数料）：9つのサービスから選択可能
特典付きチケットというのは、終演後のファンクラブ(※1）会員限定のトーク配信を見ることができたり、コンサート中の掛け声（コール）の音声を送ると曲中で使ってもらえたり、あとで紙チケットが送られてくるなどの特典の付いたチケットである。特典付きチケットはRakuten TVのみの販売（チケット販売は楽天チケットのシステムを利用）、一般チケットはRakuten TVのほか、Abema TV、LINE LIVE、huluといった動画配信系サービスや、ぴあ、イープラスといったプレイガイド系の配信サービスなど合計9つのサービスの中から選ぶことができた。
ファンクラブに入っているファンはかなりの割合、Rakuten TVの特典付きチケットを買ったと思われる。また、一般チケットを買おうとしていた視聴者についても、乃木坂46公式サイトの案内ページでRakuten TVがいちばん上に掲載されていたため、よく使う配信サービスが特にない－－といった人がRakuten TVを選んでしまったケースも多いと思われる。これが不幸のもとであった。
コンサートは19時開演予定で、Rakuten TVの視聴用ページに再生ボタンが表示されるのは18時30分。俺は当日18時ごろにRakutenTVにログインし、18時30分になったらすぐに視聴用ページをリロードして再生ボタンを押し、視聴を開始した。画質はデフォルトでは720P、540P、360P、270Pから自動で選択されるのだが、720P固定にして視聴し(※2)、映像が途中で止まることなく最後まで視聴できた（※3）。ということで、実は俺自身はトラブルの当事者ではないのだが、当日見聞きしたことや俺自身の憶測を含めて備忘のために書く
18時40分過ぎごろから、Twitterで「Rakuten TVに入れない」という嘆きが多く観測されるようになった。その中には、乃木坂46を卒業した元メンバーやアイドル雑誌編集者などもいた。そもそもログインができないらしい。開演時間近くになっても事態は解消せず、18時58分に乃木坂46公式Twitterから「開演を19時10分に遅らせる」という告知が出た。しかしその時間になっても始まらず、19時12分、公式Twitterから「もうしばらくお待ちください」という告知が出て、その後19時24分に「19時30分から開演します。RakutenTVでは翌日までアーカイブ残します」となって結局19時30分に開始された。すなわちRakutenTV難民の切り捨て宣言であった。
当然、その時点でもまだ視聴が開始できていない人はたくさんおり、公式の発表によると事象は20時12分ごろに解消されたようである。
その裏で、RakutenTVで視聴できなかった人が、次々とhulu、AbemaTVなどの他のサービスの視聴チケットを別途購入して視聴を開始するという事態となっていた。これについては、もちろん余計な出費ではあるのだが、代替サービスがあってよかったということもできる。他のサービスに流れたことで、Rakuten TVが軽くなったという効果もあるだろう。
19時30分より遅らせられなかった理由としては、公演時間を2時間30分で予定しており、22時を過ぎてしまうと高校生（※4）が出られなくなってしまうという理由が大きいだろう。実際はアンコールを迎えたあと、お別れのあいさつをしたり、手紙を朗読している間に22時を迎えてしまい、高校生メンバーは最後の１曲を披露できなかったのであった。
高校生メンバーのファンは、推しメンが大事な場面に出演できなくなったのを「Rakuten TVのせいだ」と言って悲しんだり怒り狂ったりした。
そもそもRakuten TVは何が悪かったのであろうか。大規模配信イベントと聞いて真っ先に心配になるのはネットワーク帯域や配信サーバーの性能ではなかろうか。ただし、俺の環境では通信は安定しており、視聴を開始できた人はおおむね問題なく見れていたようであった。チケットが売れた数はわかるのだから、その分の同時接続数に耐えられるようなサイジングは計算もしやすく、十分な量確保していたのではないか。
実際に俺はエラー画面と格闘していたわけではないが、ボトルネックは認証周りにあったのではないかと予想する。ログイン処理は購入者のリクエストが全部同時に来るわけではなく、分散してリクエストがくるわけだが、そのピーク時の見積もりを誤った、もしくは考慮していなかった、ということなのではないか。さらに、仮に楽天IDの処理は楽天システム共通の基盤を使っていたりすると、RakutenTVだけではなく楽天本体（？）も含めて方式を検討しないといけない事案だったのではないかと妄想する
考えられる手法としては、開演時間の3時間ぐらい前から配信を開始し、事前番組とか、おまけ映像を先に流しておくことで、ログインのピークを分散するというのがある。これをやっている動画サイトもいくつか思い当たるものもある。ただし、今回は平日の公演であり、仕事から時間ギリギリに帰ってきて急いで見る、というケースも多かったことを考えると、ログインのピークが18時30分から19時の間に集中するのはある程度避けられなかったであろう。
10月29日の午前3時過ぎ、楽天チケットから届いたメールに以下の文章があった
尚、アクセス集中により本公演が開演時間からご視聴出来なかったお客様におかれましては、速やかに弊社およびRakuten TVにて確認を行い、別途改めてご連絡をさせて頂きますので今しばらくお時間を頂ければと存じます。
おそらく、配信サーバの接続ログを洗い出し、購入者のIDと照らし合わせて、それぞれ何時何分から何時何分まで接続していたか集計するのであろう。おそらくそういう用途を想定した出力形式ではないであろうログファイルを整形して集計する作業を必死でやっているエンジニアにはご自愛くださいと言いたい。
なお、この影響はサイト全体に及び、プロ野球パ・リーグ視聴権の年間契約している人がRakuten TVで試合を見られないという事象も発生した。中にはパ・リーグ事務局が直営で運営している配信サイトの1日視聴チケットを別途購入した人もいたようである。
※1 正確にはファンクラブという名前ではないが、便宜上そのように呼ぶこととする
※2 720Pの映像は4Mbpsの帯域を使用するが、住んでいるマンションの固定回線が速いときは200Mpbsぐらい出るものの、ときどき2Mbpsぐらいまで落ち込むこともあり、安定して視聴するために、あえてスマートフォンのテザリングで4G回線を使用して視聴した。転送量は7GBほどだったが、ギガホの残り容量がかなり余っていたので問題なかった。
※3 終演後のトーク配信のなかで、バスに乗って移動しながらトークするコーナーの途中で映像が止まる事態が発生したが、これは映像制作側の中継用機材の問題であって、配信サービスの問題ではない
※4 労働基準法で22時以降の労働が禁じられているのは18歳未満のため、芸能事務所によっては18歳の誕生日を迎えた以降なら深夜の番組等に出演させることがあるが、乃木坂46では18歳以上であっても高校生には22時以降の仕事はさせない契約になっているようである。もっとも、22時の時点で画面に映らなくなればOKという運用なので、その後の楽屋での片付けや着替えも労働ではないかという疑問はある。
それは先週金曜日のことだった。
慌ててCOCOAを起動して確認するも、「陽性者との接触は確認されませんでした」との表示が。
新型コロナウィルス流行後、いわゆる三密に相当する施設は避けてきた。
買い物に行くときも、自家用車を利用してきた。新型コロナに感染するような覚えは全くない。
さっきの通知は何だったんだ？そういえば、COCOAはバグがいろいろ残っているというし…
急いでCOCOAの不具合について調べると、似たような現象に直面している人はいるらしい。
どうやら、携帯の設定項目をたどると、接触ログを記録したjsonファイルが書き出せるので、
そのログの中を検索し、Match Countという項目が0以外になっている箇所があれば濃厚接触があったという事らしい。
…残念ながらMatch Count :1となっている箇所を発見。陽性者と濃厚接触している。
それからが大変だ。
厚生労働省のCOCOAに関するQ & A の問23に、上記のような不具合が起きたら問い合わせしてほしいとの記載があったので、
状況を記載して、証拠となるjsonファイルを添付した確認メールを送付。
職場の規定でCOCOAに反応があった人は2週間の出社停止なので、すぐに会社に連絡を入れる。
同時に、陽性者との濃厚接触した日付がわからないので14日以内に会った人に注意喚起の連絡。
14日以内に会った人でCOCOAを入れていた人には、バグの存在とjsonファイルから確認する方法も説明。
今回はたまたま14日以内に会った人が全員職場関係のエンジニアだったので難なく説明できたが、
はあ、疲れた。感染拡大防止のためとはいえ、アプリのバグのせいで無駄な仕事が増える。
正常系のテストもまともにできていないであろうCOCOA開発元に対して若干の怒りを覚える。
さすがにこの完成度の低さはないだろうとネットで情報を収集していると、ずさんな開発体制(物理的に無理のあるリリース日程や、2つ動いていた開発プロジェクトの1本化など)であることが判明。
ちなみに、この不具合は今日現在の最新バージョン1.12でも改善されていないし、改善予定のアナウンスもない。
今時スマホゲームですら、ちょっとした不具合(例えば、アイテムの効果が正しく設定されていなかった等)に対しての修正予定を公開しているのに、
下手すりゃ人命にかかわるアプリがバグ自体を公にせず、修正予定も公開していないことに苛立ちを覚える。
そして日曜日。確認の問い合わせを送っていた厚生労働省から返信。
メールの内容の転載はやめてくれとの記載があったので、転記は控えるが、要旨を書くと
「ポップアップが出たのにアプリで接触履歴が確認できない場合はiOSまたはAndroidの設定から接触チェックの項目を確認してください」とのコピペのような文章。
まあ、サポートも問い合わせ殺到しているだろうし、返信遅れるのは仕方ないなと思っていたが、
きっちりログファイルまで送って濃厚接触していると思われるのだがどうでしょうかと聞いてこの返答はあまりにも人を馬鹿にしてるなと思った。
多分、急にサポートに人手が必要になったので、バイトをかき集めて適当に回していると思われる。
それにしてもだ、そんな適当な回答をするなら初めからQ & Aに設定から接触チェックを確認して1以上なら接触しているとの前提で行動してくださいと書けばよいだろうに。
ちなみに、8/19日12時現在でも厚生労働省のQ & Aは下記のままであり問い合わせるようにとの文言になっている。
問23 陽性者との接触があったようなプッシュ通知が表示されましたが、接触確認アプリを開いて陽性者との接触を確認すると「陽性者との接触は確認されませんでした」と表示されます。どちらが正しいですか。
Android搭載のスマホをご利用の方は、問２１、問２２をご確認ください。これらで解決しない場合、またはiOSをご利用の場合は、大変お手数ですが、メール（appsupport@cov19.mhlw.go.jp）にてご連絡いただきますよう、お願いいたします。
さて、話はアプリの完成度が低くてストレスがたまったという話だけで終わらない。
私が周囲に反応したという事を報告したせいで、思わぬ影響が出たのだ。
職場の同僚が、私の濃厚接触者だったという事でコロナマン扱いされて出社するのは軽率だと怒られ問題になるという事件が起きたのだ。
アプリのバグのせいで私が陽性者と接触した日がわからないため(正常に反応するケースでは接触日がわかるとのこと)、
最大2週間のマージンを取って、その間にあった人全員に連絡をしたのだが、
彼自体は私が陽性者と濃厚接触する前に私と合っただけかもしれない。
それならば完全に風評被害だ。ちなみに私も私の濃厚接触者も全員体調に問題は起きていない。
話は長くなったが、このアプリにいろいろ思うことはある。
まず、陽性登録者が200人程度の時点で反応したという事でコロナの影は意外に身近にあると感じられたこと。
これで全陽性者が登録していたらえらいことになっているだろう。
次に、このアプリが反応した時の社会の対応指針が現状ではうまく設定されていないこと。
現状では反応が出ただけの人間のその接触者までもがコロナ陽性者と同じ扱いを受けて、社会的に行動制限を課されてしまう。
アプリを活用するための合理的な指針が社会に浸透することを望む。
そもそもBluetoothの電波強度で濃厚接触を判定しているため、近くにいても濃厚接触にならないケースがあるだろうし、
十分距離を取っていても濃厚接触とカウントされる恐れがある。(携帯のBluetoothモジュールのアンテナ次第で当然電波強度の指向性出るよな?)
また、アプリで反応が確認できないというのは論外だし、確認できても次のステップにつながらない。
例えば、LINEアンケートでたまに送られるようなアンケートが自動的に配信され、怪しい兆候があれば医療機関のデータベースに登録され、優先的に取り次げる等の工夫がほしい。
私自身はなんだかんだで感染拡大防止しないと社会も経済も正常に戻せない思っているタイプなのでできる限りの協力はしたいのだが、アプリの完成度の低さには正直あきれ返っている。
最近は真面目に感染拡大防止をする人間を「コロナ脳」とかいって揶揄する人がTwitterをはじめとするネット上に増えた印象を受ける。
GoToキャンペーンなんかもそうだけど、正直者が馬鹿を見る社会システムがこうした問題を拡大させているように思う。
昨今流行りのNTTの退職エントリの大半において、NTTの評価は
・福利厚生は良い
・人も良い
・待遇も悪くはない
・的外れなセキュリティ対策にガチガチに縛られていて作業効率最悪
という感じなのだが、まさにその通りなので、退職する気はないが、現役社員として実例を示しておく。
私が所属する組織では、ここ数年で情報セキュリティインシデントが多発している。
具体的には、取引先のベンダーA社の情報が、B社に開示されてしまうという情報漏洩だ。
その大半が、弊社の独自システム（以降「システムX」と呼ぶ）上、あるいはその周辺で発生している。
システムXは、弊社と多種多様なジャンルのベンダーが仕様書やソースコード、バグ票やQAコメントのやりとりなどを行うためのプラットフォームなのだが、その歴史は古く、運用開始は2000年代前半。
運用当初から現在に至るまで無秩序な機能の追加や他システムとの統合を繰り返した結果、その全貌を知るものは最早いないのではないかという複雑怪奇なシステムとなっている。
それゆえに情報管理・権限管理の仕組みは非常に難解で、「どうぞヒューマンエラーを引き起こしてください」と言わんばかりの罠が方々に散りばめられている。
「A社宛の起票のつもりだったが、なぜか権限設定に不備があり、B社も閲覧可能になっている」といった具合だ。
さらにシステムXへのユーザアカウント追加／削除や権限設定は、これまた極めて複雑かつ前時代的なエクセルフォーマットに記入してメールで申請しなければならず、この申請方法に起因したヒューマンエラーによる情報漏洩も後を絶たない。
日本語の読み書きとITパスポートレベルの知識があれば、わが組織で発生している情報セキュリティインシデントの癌はシステムXだということがわかるはずだ。
システムXの問題点を洗い出し、別のシステムでの代用を考えるのが筋道であろう。
現に、開発プロジェクト単位でシステムXを使わずにbacklogやJIRAといった権限の管理が容易かつ確実に行えるシステムへの移管が進んでいる。
問題。情報セキュリティインシデントの多発に伴い、社長や直属役員からお叱りを受けた組織長が取った対応策は何か。
もちろん本日記のタイトルからお察しの通り的外れなのだが、その度合いがヤバい。心して聞いてほしい。
・メールやシステム（システムX以外も含む）で社外に添付ファイルを送信する際は、課長職以上の管理職から送ることとする。
・具体的には、係長以下の社員が添付ファイルの所在および送信方法の下書き（メールやチケット）をメールで管理職に送り、管理職が先方に送信する。
・・・え？
システムXが糞過ぎてヒューマンエラー多発してるだけなのに、全てのファイル送信を管理職が送ることで何か解決するの？
というかメール／JIRA／backlog／Redmine etc・・・で日に何十も何百もファイル送信が行われるのに、全部管理職を経由させるの？
ログファイル1件、スクリーンショット1枚送るのに課長にメールで依頼して、対応を待たなきゃいけないの？
働き方改革だ、業務効率化だと言っていたのはどこの誰でしたっけ？
もうね、怒りを通り越して笑いがこみ上げてきたよ。
この対策（笑）が意味を成さないこと、むしろ無駄に人手をかければ更にヒューマンエラーが発生する確率が上がることくらい、ちょっと賢い小学生でも理解できる。
気づいてる管理職も大勢いるはずなのに、誰も異論を唱えず、淡々と部下に"ルール"として周知する。
多くの部下を抱え、毎日大量のファイル送信が必要な管理職は、ノートPCを持ち帰り、帰宅後だろうと年休中だろうと遠隔でファイル送信の対応に追われている。
わが組織に「ボトルネック生成によるヒューマンエラー促進法」が施行されて数日後、めでたく情報セキュリティインシデントが発生した。
具体的な内容と原因については知らされていないが、推して知るべしといったところ。
いっそのこと、ファイルは全部組織長が送信したらどうっすかね？むしろ、社長にしますか？いや、それでも危ないから、全部手渡しにしましょうか？（鼻ホジ）
PostgreSQLは普通に使いながら覚えられるって言ってんじゃん。
MS SQLServerも「とりあえず動かしてみる」から始めることは不可能じゃない。
ユーザやグループの設定から始まり、どういう単位でデータベースを作り、どのユーザをどのデータベースの所有者にするか、ログファイルの種類とそれに基づくバックアップ計画がどうのとか、とにかく覚えることが多い上に複雑過ぎて、予備知識無しで触ることはまず不可能。
てか、たかがRDBMSにそんな大げさな仕組みが必要か？って話。
PostgreSQLのようにシンプルな仕組みが基礎にあって、そこから要件に応じて機能拡張できるような柔軟なソフトを知っちゃうと、こう意味もなく最初から色々お仕着せ状態なのはイライラでしかないし、すげーバカバカしく感じてしまう。
原文：https://community.spiceworks.com/how_to/125475-teslacrypt-2-2-0-removal-and-decryption
原題：TeslaCrypt 2.2.0 Removal and Decryption
原著者：Isaac Rush's (hewhowearsascarf) Portfolio of IT Projects - Spiceworks 氏 (Thank you for your contribution! This article is a translation of your post.)
私たちのワークステーションのうちの一つがTeslacryptランサムウェアに感染しました。すべての文書が暗号化され、拡張子はvvvに変えられました。マルウェア感染のにおいて最も安全な回復方法はコンピューターをワイプしてバックアップから復元させることです。しかし、それは場合によっては選択肢にならないことがあります。私たちの場合、ユーザはローカルコンピュータに何のバックアップもとっていませんでした。それで、私たちはランサムウェアを取り除く方法とファイルを復号する方法を確認する必要がありました。復号を達成させてくれたPythonスクリプトの作者であるGoogulatorに大きな感謝を送ります。https://github.com/Googulator/TeslaCrack
そこに書いてある説明に従うといいです。引用していくつか説明を付けたものを以下に用意しました。元の記事にはたくさんの指示が書いてありますが、私たちが行った手順は以下の通りです。
セーフモードで再起動し、Malwarebytes scanを走らせて、見つかったすべてのマルウェアを削除します。私は複数の信頼できるマルウェアクリーナーを使ってこれが消えたか確認することをお勧めします。必要だと言われたら再起動します。これでウィルスはきれいになったはずです。次はドキュメントを復号します。
私たちはPythonスクリプトを使って、AES公開鍵を特定して、その数値を因数分解して、それから秘密鍵を特定して、そしてファイルを一つ復号します。一度復号に成功したら、コンピュータすべてを対象に実行できます。できるなら、多く速く処理するために他のコンピューターを使ってください。
インストールは管理者権限で行ってください。また、インストール中の操作で、Pythonをパスに追加するオプションを必ず選択すること。
python -c "import urllib2; print urllib2.urlopen('https://bootstrap.pypa.io/ez_setup.py').read()"; | python easy_install pip
pip install http://www.voidspace.org.uk/python/pycrypto-2.6.1/pycrypto-2.6.1-cp27-none-win_amd64.whl
pip install ecdsa
私の実行結果は以下の通りです:
Cannot decrypt ./VENDOR LISTING BY CATAGORY.xlsx.vvv, unknown key
Software has encountered the following unknown AES keys, please crack them first using msieve: A1373BCF4EDB39BCFEDD44FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0 found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv
Alternatively, you can crack the following Bitcoin key(s) using msieve, and use them with TeslaDecoder: 5ECA19D475A313AC3DEF915CE6FA37BE012CD1676590C8F253135A3AD92345B78C32C46DB3246ED84A7B9A8C62F1A13D2AF08F09FFB3551701E7B75CCC79457C found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv
私の場合は以下の値をコピーしました。 A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0
さっきの数値はこのようになります: 8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640
私の場合だと、8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640 を入力して「Factorize!」を押してみました。もしあなたがラッキーなら、画面の左端には「FF」と表示されるでしょう。これは完全に因数分解されていて、すべての因数がリストされていることを意味します。この場合、あなたは以下のyafuを使う手順を行う必要はありません。unfactor.pyのところ(訳者注：手順19)までスキップできます。
もし「CF」や「C」と表示された場合、私たちはまず因数分解をするためにyafuを実行する必要があります。因数分解ができたら、 factordb.com に戻ってその整数を下のほうにあるレポートフィールドからレポートしましょう。そうすることで、その数値が「FF」で表示されるようになります。因数分解は数値の複雑さによって数時間・数日間・数週間かかります。因数分解が終わったら、私たちは秘密鍵を得るのに使用するたくさんの数値(因数)を得ていることでしょう。私はmsieve, yafuとこれらのバリエーションを試しました。これを動かすのは結構大変でした。いくつかの問題は説明が不完全で、すべての構文を与えられていませんでした。しかし、ついに私はyafuを動かしました。私が何をしたか、以下に書きます。
例: yafu-x64.exe "factor(8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640)" –v –threads 4
因数分解を始めると、小さな因数は素早く見つかり、このようにリストされるでしょう : 「div: found prime factor = x」。ログファイルの中から「found prime factor」を検索します。
さらに「prp」も検索します。このような行が見つかるでしょう。: prp32 = 25647545727466257054833379561743
これが私の実行結果です:
unfactor-ecdsa.py VENDOR.xlsx.vvv 2 2 2 2 3 5 367 12757 25647545727466257054833379561743 75938537910569673895890812481364802067167 3858259146292441335085163995598583072203543699186432807503634945432314399
Found AES private key: b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88' (BDA2543A2175B9F30DF6F30960EC082F3EC5EF61D403A35BC1477E10470A7C88)
'A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0': b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88',
ファイルが復号されるはずです。
あなたの重要なファイルをバックアップしましょう！できればすべてのシステムで。同じようなことが起こった場合でも、回復するために無数の時間を使うかわりに、バックアップから復元できるようになるから。
きっとこれらの追加の手順は皆さんを助けます。自分がこの手順を行ったときはたくさんの問題がありました。それでもしあなたがこれを不完全だと思うなら、手順を更新するのでお知らせください。たぶん私たちはいっしょにこの手順をより完璧にすることができます。ありがとう！
https://community.norton.com/en/forums/how-decrypt-teslacrypt-vvv-files
http://www.mobilefish.com/services/big_number/big_number.php
http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html
http://www.mersenneforum.org/showthread.php?t=20779
エディタで。vimのキーバインドで。teratermの背景色で。ログファイルの名称で。変数名で、タブの桁数で。spfileの設定で。jbossの設定のおまじないで。stratsの継承方法で。エラーのクラス名で。プロパティ名で。セッター、ゲッターを付けるかつけないかで。コンストラクタで。newを上書きするかしないかで。jreのeditionで。eclipseの見た目で。javadocのエディションで。クラウンのドキュメントIDで。githubにいくつ持っているかで。tryのインデントで。タブを表示するかしないかで。エディット中の飲み物で。待ち合わせはスタバなのかエクセルシオールなのかで。セブンイレブンのコーヒーのサイズで。そのコンビニのコーヒーが一番うまいかで。IDカードは伸びるストラップがいいのか悪いのか。寝るときは机の下か椅子を並べるのか。デスクの上にフィギュアは置いていいのか悪いのか。めんまかつるこか。
何を言いたいのかというと、Ubuntu One for Windowsがさっぱり同期を行おうとしないという点なのだが。それも同期が起動しないとかならまだいい(いや良くない)が、たった200kBのテキストしかないのに「同期を開始しました」のまま何時間放置しても終わらないというのが終わってる(明らかにプロセスが停止している)。Ubuntuの側でやるときちんと同期が完了するので、多分Ubuntu One Win側の問題なんだろう。
で、終わらない理由を探そうとしてログを見ようとするが、このログも吐いている気配がない。ローカルファイルにもシステムログにも動作ログファイルがない。WindowsのシステムログはLinuxのそれとは大きく違うが、機構をオミットする程難しい使い方ではなかったような記憶があるのだが。
SkyDriveの対応は永久に望めないだろうし、Google Driveも(ここは色々と問題があるのだが)当面対応しそうにない。これでUbuntu Oneも使い物にならないとなったら、結局Dropboxでも使っとけという話になるんだろうか。それでいいのかUbuntu One。
