久しぶりにkubernetesの実験をしようと思ってminikube起動したら上記のようなエラーが出た。対処方法について書きます。
docker ps -aで状態を確認し、起動せずに終了しているminikubeインスタンスを見つけ削除すると良い。
再度、minikube startで復活できるはず。
タグ: Docker, error, Kubernetes, Linux, minikube
2021年3月15日Windows Hack, トピックス, ノウハウ, 雑学TIPS
先日、普段使うことの無いMicrosoft Teamsを使用する事があり、認証が通るがその後のコールバック処理でTeamsのダッシュボードに遷移せずに「HTTP 400 エラー」や 400 Bad Request Errorが出て全然使えない問題が生じた。ことの発端は、常に会議の１時間前にオンライン会議のログインテスト（映像、スピーカー、マイク）を行う儀式を必ずするのだが、顧客から送られてきたリンク接続先がまさかのMicrosoft Teamsのリンクだった。いつもならZOOMなんだけどね。まさかのログイン認証後にエラーが生じる問題が発生しそこからが問題解決にたどり着くまで一苦労だった。結果的には３時間で解決したがこんな問題もあるんだなーと。認証方法を変えたらログインできたので同じような方がいましたら参考に。
勝手にTeamsが昨年秋ごろにPCへインストールされたんだけど、使わないのでアンインストールしていた。今回は会議があるので再度インストールしないといけない。インストール自体は簡単なのですぐ終わるのだが、仕事柄、複数のアカウント（お客さんの代行作業）を持っているのが仇となり問題につながった。インストールしたTeamsは勝手にお客さんのアカウントでログイン状態になっていた。それはまずいのでサインアウトして自分の会社のマイクロソフトアカウントを使ってログインするのだが、何故かMicrosoft Authenticate認証は成功するのに、その後のコールバック転送でTeamsにダッシュボード画面を表示させる段階で「HTTP 400 エラー」「400 Bad Request Error」になってしまう。
パスワード変更を試みたり、パソコンを再起動をしたりしたが全く問題は解決せず、マイクロソフトのフォーラムなどで似たような現象をもった人たちがいたようだが大部分は解決できていないようだ。
結局、実際のオンライン会議はWEBブラウザー経由でどうにかなったが、Teamsってブラウザ経由だとイマイチなんだよね。カクカク動画が動くし、音飛びもよくするし。
終わったあとに再度考え直してみました。認証は通っているがダッシュボードに移行しないのはユーザアカウント＆端末でプロファイルはTeamsのセンター側で保持されているのだが、何らかのバグで認証の成功ステータスをプロファイルのDBに書き換えできていないのだろう。ならば、認証の救済で別の認証方法が他に３種類ほど選択できるのでそれを試すとしよう。もしかするとプロファイルの書き込み項目が変われば通る可能性はあるかもね！
この予測は多かれ少なかれあたってたんじゃないかな。結果は大成功でした。最初はMicrosoft Authenticaterがスマホに表示する３つの数字とTeamsの認証(MFA)で生成される数字の一致を確認しスマホ側の一致する数字のボタンをタップする方法は認証は成功してもTeamsへコールバックでエラーが生じていました。しかし今度はSMSで登録したスマホへワンタイムパスワードを送る方式に変えたところ転送が一瞬うまく行ってダッシュボードが表示されたタイミングでTeamsが落ちてしまった。でもここまで来たなら恐らく次の起動でうまくダッシュボードにいけるだろうと再度Teamsを起動したらようやくダッシュボードにたどり着きました。やっと成功です。
※下記は画面遷移（認証後のコールバック）で失敗した時の認証方式です。認証自体はもちろん成功しています。
※下記は画面遷移（認証後のコールバック）で成功した時の認証方式です。
以上似たような現象が発生した方は、参考にされたし。
タグ: Authenticator, error, MFA, teams, 認証
Google Search Consoleの404エラーはSEO上重要なファクターです。Googleは404エラーは評価無視扱いとされ、色々な説がネットで流れていますが結果論から言ってしまうとエラーの割合が多いと順位が確実に下がります。つまり直接理由ではなくて間接的な要因から順位が下がってしまいます。ここには隠された謎があります。というのは通常４０４エラーは検索結果のリンク表示をクリックしたときに「ファイルがありません」というものを表すのですが、実はそれだけでは無いのです。ここをじっくり見ると攻撃の跡が見られます。つまり、隠されたページやバグを見つけようとして、あの手この手で存在していないURLを作り出してアクセスしてきていることがわかります。GSの管理画面でクロール＞クロールエラー＞URLエラーの項目を是非チェックして見てください。おかしいなと思うURLがあるはずです。ほぼそれが攻撃の形跡だと思います。
先に述べたように有りもしないページは勝手にアタックさせておけばと考えるのですが、意外と短い時間で連続アクセスされるとサイトによっては重くなる要因です。ページが重くなったら機会損失ですし、今は表示速度は評価の一つです。その他404エラーは間接的に色々なファクターを持っており、Googleがインデックスを刷新するタイミングを作る意味もあります。いい意味でコンテンツの切り替えがあって404エラーになってしまう場合もあります。これは健全な404エラーで全く問題ないのですが、ここにさらにページの生存期間が加わってくるとややこしいことに。
ページがきちんとGoogleに認識するまでの期間は意外と時間がかかります。私の感覚では更新ページが少なければ1日、2日で認識されるのもありますがページ数が多いと2週間から1ヶ月弱までかかる場合も多い。それで1ヶ月程度でネタが更新されてゆくともうお分かりでしょうが認識されず生涯を終えるページもあるわけです。
つまり新しい記事ネタでもページURLは変わらずページBODYのみ定期的にダイナミックに変わるものが最も有利な構造と言えます。最初からデータベースでBODYコンテンツをダイナミックに作ればよいのでしょうが、図体のでかいサイトは簡単に変更できません。今はスクレイピングの技術やJavascriptの技術があるから置換したり局所的にはめ込みを更新するのは簡単なことです。私は実験で自分自身が持っている幾つかのサイトを完全ファイル構造を変えて刷新することをやってみましたがやはり全てのGoogle検索サーバが完全同期するまでには半年以上かかりました。その間は何度もGoogle Search Consoleの中で重複や404エラーの先祖返り評価を表示されることがあり、改めてGoogleの検索サーバの同期はものすごい時間がかかるので、ディレクトリ構造やファイル名をあんちょこにコロコロ変えるのは得策ではないとわかりました。
エラーはサイトの健康のバロメータであることはわかったかと思います。エラーが少ないにこしたことはありません。多いということはそれだけ無駄が潜んでいたり、セキュリティアタックを受けてたりと色々なことがわかります。セキュリティアタックなら攻撃パターンが分かれば対処は難しくありません。意外なところで便利な404エラーですね！皆さんも要チェック！