2015.03.15

妻からの誕生日プレゼント

誕生日には少し早いですが、妻より誕生日プレゼントを頂きました。

abrAsusの薄い財布

これのダンボーコラボバージョンです。

 

妻は元々ダンボーグッズを求めて「よつばとダンボーストア」を覗いていてこの財布にたどり着いたようです。(おとよがダンボー好きなため)

二つ折り財布の宿命でもある、カード入れの革とコイン入れとが重なったことにより分厚くなる財布を配置と革の使い方を極限まで合理化して、二つ折り財布で信じられないほど薄く縫製されているのが特徴です。

 

特にコイン入れの部分がすごい。カードケースに重ならないよう平行してレイアウトされています。

コイン入れは説明書によると999円まで入る設計。つまり枚数限定。

カードケース部は一枚一枚仕切りの革があるのではなく、5枚分のスペースが確保されているだけ。

お札は15枚まではさむことが出来るようになっています。

 

つまりこのお財布は何でも入る財布ではなく、メインのお財布はカバンの中に入れておいて、胸ポケットなどに入れておくちょっととりあえずのお財布に特化しています。 コンセプトを割り切ったからこそ出来ることなのでしょうけれど、そこに着目した二つ折り財布というのは見たことがありません。

お金・カードを入れた状態で横から見てみると確かに薄いです。

実際にシャツの胸ポケットに入れても全然邪魔になりません。

 

プレゼントされてから数日経過して、すでにお気に入りのお財布となっています。

おとよのメインのお財布は長財布なので、こういうコンパクトなお財布はちょっとしたお買い物で非常に役立っています。

 

素敵なプレゼントをチョイスしてくれた妻に感謝!!です。

 

2015.03.08

google 二段階認証の万が一に備えYubico U2F Security Key

昨年(2014年)5月ごろ中国からの大規模なGoogleアカウント乗っ取り騒ぎがありました。

それ以前からもGoogleアカウントはユーザー数が膨大であるがゆえに乗っ取り攻撃の標的にされてきたわけですが、Googleからの乗っ取り対策として安易なパスワードではなく、より複雑なパスワードや2段階認証が推奨されています。

 

おとよは2012年12月に2段階認証を導入し、スマホでワンタイムパスワード発行するようにしました。

これはこれで良いことなのですが、ちょっと困ったことがあります。

 

それは2段階認証アプリが入っているこのスマホがアクセス不能な状態になるととっても面倒なことになるということ。

googleアカウントでは2段階認証が利用できない場合は電話認証で使用した電話番号へワンタイムコード発行など色々バックアップ手段は用意されているのですが、その電話とはまさに2段階認証アプリが入っているスマホなので、すべてのリスクはスマホに集中していることになります。

 

2011.03.11、たまたま東京に出張していて宮城県沖地震(東日本大地震)と遭遇したのですが、あのときの携帯通信網の脆弱さは結構怖いものがあります。

宿泊先のホテルでのネット回線は遅いながらも利用できたのですが、モバイルはひどいものでした。

また、あの混乱の中、スマホを落としたり、揉みくちゃになって壊してしまうリスクもあります。

そうなると、2段階認証そしてバックアップの認証手段はすべてなくなってしまい、Googleアカウントは実質利用不可になってしまいます。

 

このリスクを回避するため2段階認証を諦めるというのもありますが、それではアカウント乗っ取りリスクが増大します。 よって2段階認証を生かしたまま、2段階認証とは別にスマホに依存しない認証方法を導入することにしました。

それが、最近Googleのアカウント認証で採用されたU2F方式のセキュリティトークンを利用した認証です。

 

写真のモノは“Yubico”社が販売しているU2F方式に対応したセキュリティトークン。

日本ではまだ馴染みがないためか正規販売店はなく、日本のAmazonで並行輸入品が販売されているくらいです。

アメリカ/イギリスのAmazonで購入することも出来ますが、Yubico社の通販ページでセキュリティトークンが$18、送料はAirMailで$5となっており、この方法での調達がもっとも安価です。

 

発注すると大体1週間ほどでAirMailで送られてきました。

 

Yubi KeyでGoogle認証を利用するにはGoogle Chromeが必要です。(Chrome拡張機能で動作するので)

よってGoogleアカウントにYubi Keyを登録するにはChromeをインストールされていることが前提としてそこからの作業となります。

 

まずはGoogleにアクセスして、自分のアカウント設定に移動し、2段階認証プロセスを呼び出します。

 

2段階認証のページでは、セキュリティキー・タブを呼び出します。

 

セキュリティキー追加のボタンを押します。

 

Chromeに拡張機能がダウンロードされ、セットアップが完了したら登録ボタンを押した後、Yubi Keyをパソコンに挿します。

 

Keyを認識すると、Keyをタップするように指示が出ます。

このとき、Yubi Keyの真ん中にある鍵マークの金色の部分が点滅しています。

指でここを触ると、パソコンにセキュリティトークンが送信されます。

 

セキュリティトークンを受領すると、登録完了となります。

 

では実際にテストしてみましょう。

とりあえずパスワードなどを無効にするため、Chromeをシークレットモードで起動します。

 

Googleログイン画面でユーザー名とパスワードを入力します。

 

セキュリティトークン挿入の要求画面となります。

ここでYubi Keyを挿入し、登録のときと同様、点滅する鍵マークのところをタップするとログインが出来るようになります。

 

また、セキュリティトークンを利用しない2段階認証利用可能です。

 

なお、複数アカウントを持っている場合は、それぞれのアカウントに同じYubiKeyを登録することが出来ます。

いかがでしょう。まだ日本ではあまり利用者が少ないYubi Keyですが、Googleアカウントを保護しつつ、スマホにリスクが集中して万が一が発生したときに途方に暮れないようにするにはかなり有効な方法かと思います。

 

今回トークンを入手したYubico社にはこのU2Fセキュリティトークン以外に、ハードウェアワンタイムパスワード用トークンや、NFC通信付きのスマホ用トークンなどバ リエーションが増えてきていますので、今後はこういうトークンが人の記憶に頼らないパスワードの基本となるのではないかと思います。

 

難点は…日本での入手ルートがまだ特殊ということですね。

 

2015.02.27

サーバー不幸の連鎖その3(歯切れの悪い完了)

WordPressのプラグインのお陰でMySQLのDBの修復も完了し、仮想サーバーやVMWare含めたシステム全体を再起動すると新たな問題が発生していました。

 

今度はこれまで無事に動いていたWEBサーバーも動作しなくなっています。

厳密には、旧サイトは普通に動いていますが、このblogを格納している新しいWEBサーバーがエラーを出しています。

何度かサーバーを再起動して傾向を探ろうとしますが、

 

Apacheから“503 Service Unavailable”エラーで落ちる場合と

WordPressから“データベース接続確立のエラー”のエラーで落ちる場合

 

この二種類あるようです。

どちらも起動したてのサーバーでは考えにくいエラーです。

特にApacheのエラーはサーバーリソースが枯渇した場合に出るエラーで、安定稼働していたApache設定ファイルには何も手を加えずシステム再起動して出るような類のものではありません。

旧サイトは正しくつながっているので、少なくともリバースプロキシのApacheは正しく動作しているようです。

 

そして起動時のログを追いかけながら、何度か再起動を繰り返しているとおかしな傾向が見えてきました。 サーバーの起動にかなり時間が掛かっているということに・・・

 

システム全体の再起動では、親サーバーが起動した後スクリプトでVMWareをバックグラウンドで起動し順次仮想サーバーを起動していきます。 同時実行するとサーバーの起動順序がバラバラになるので一つ一つの仮想サーバーの動作が確定してから次の起動に移ります。

よって複数のサーバーで起動の時間がかかっていると全体の起動完了が非常に時間が掛かることになります。

それぞれの起動を追いかけて行くと、途中で引っかかっているシーケンスを発見しました。

 

netfsサービス…NFSです。

 

本来ならばVMWare内の仮想ネットワークでのNFS接続なのでそんなに接続に時間がかかるとは思えません。

しかし、確実にNFSでつまづいているようです。

再起動してログイン画面が出、システムにログインし、dfコマンドでマウント状況を確認するとログインした段階ではまだNFSマウントされていません。

数分経過してからdfで確認するとNFSマウントされているので、どうやらバックグラウンドモードで再接続を試みているようです。

ただWEBサーバー / MySQLサーバー / sambaサーバーこれらはNFSマウントされた先のデータを利用していますので、こんなに遅くマウントされることは想定していません。 どうやらこれがエラーの諸悪の根源のようです。

 

対策としてはNFSクライアント設定でnfsvers等CentOS同士だから・・・と、デフォルト解釈で任せていた部分を明示的に設定。

出来ればサーバー起動前にNFSマウントを保証したいのでバックグラウンド接続はやめてフォアグラウンド接続の設定にしたかったのですが、それだと今回のような場合ハングアップ同様の状態となりかねず、もっと深刻な問題になりそうなので一旦見送り。 さらにsambaについてはsambaの設定(smb.conf)において接続先IPアドレスだけでなくネットワークインターフェース名(eth1等)を明示的に設定。

 

これら設定を行ってシステムを再起動…安定接続できるようになりました。

 

何れのサーバーもクライアントからの接続とNFS接続を分離し、仮想とはいえDUAL LAN構成としていたのでここに問題があったのかもしれません。

・・・ここで「かもしれません」と歯切れの悪い記載になっているのは、本当にそうなのか…と、設定を元に戻して再起動すると今度は何事もなかったように起動して来て不具合の再現性が無くなってしまったためで、本当にこの設定が決定打なのか…じつははっきりと言い切れないのです。

 

ただ接続設定が明示的ではなかったのは事実で、その設定自体がなにか悪影響するわけではないと思います。

なので今回はこの設定のまま運用を再開することにしたのですが、やはり内心は不安です。

 

暫く様子をみて、また何かあるようであれば追いかけてみたいと思います。(こういう体験はできれば勘弁願いたいですが…)

2015.02.25

サーバー不幸の連鎖その2

WEBサーバーが観れなくなっている原因を探ろうとノートパソコンを起動しようとしたら、まさかのsambaサーバーの同時不調。

危うく無実のノートパソコンがクラッシュしかけの状態まで行き、やっとの思いでサーバーのメンテナンスを開始。

 

まず行うのは、外部(WAN)側からの接続は駄目で、では内側(LAN)からのアクセスはどうか。

 

コチラは問題なし?…いやなんとなく重い…でも一応機能はしている。

 

特にWordPressにログインするとものすごく重い。

ここで疑ったのはeo光と接続しているアクセスルーター。

しかし、おとよが採用しているのはマイクロリサーチ社のSuperOPT100E

民生用ながら空気のような存在とまで言われる信頼性の塊。

先代のSuperOPT50も同様に信頼性の塊で10年以上使用していたものの、本体ではなく電源(ACアダプタ)が壊れたので買い換えしてまだ2年ほど。

そうそう考えられない事ながら念のため、普通にインターネットに接続。

 

コチラ問題なし。快調。

 

仮想マシンが不調なのか?? と、念のため別仮想マシンで動作しているメールサーバーを外部(WAN)/内側(LAN)からアクセスしてみる。

 

外部(WAN)NG / 内側(LAN)OK。

 

WEBサーバーとメールサーバーがまったく同じ挙動…ということは、仮想マシン個別の話ではなくて、

 

1.VMWare自体がおかしなことになっているのか

2.VMwareを動作している親サーバーがおかしなことになっているのか

3.インフラ(Internet)がおかしくなっているのか

 

この三つに想定要因が絞られる。

続いて確認したのが、アクセスルーター(SuperOPT100E)はLAN側に簡易DNS機能を有しているので、LAN側からのサーバーアクセスでは簡易DNS機能を使用していることから、外部のDNS…とくにこのwendy-net.jpがちゃんと外から見えているか。

これは我が家の固定IPで直接外部から接続してみるとわかる。

 

結果、IPアドレス直接アクセスではOK / ドメイン名アクセスではNG

 

どうやら原因は見えてきた、ドメインを管理しているdnsサーバーが怪しい。

 

そこでnslookupを使用して”wendy-net.jp”が登録されているns.mydomain.jpと比較用にgoogleのdnsにアクセスしてみる。

ビンゴです。 dnsサーバーが落ちています。

pingを打ってみると応答ありなので、センターが物理的に落ちているのではなくて、ホスティングサーバーが落ちているっぽい。

原因はわかったものの、私の手の及ぶところではないので、とりあえずドメイン管理会社にメールで連絡。

この時点で日曜日の夕方になっていたので、実際に対応いただけるのは早くて明日。 気長に待つしかないでしょう。(困るけど)

 

しかしそれでも、なぜWAN側からアクセスされることのないsambaや、WEBサーバーが極端に重くなっているのか…この問題が解決していません。

とくにsambaの不調は深刻で、お家のすべてのパソコンがログイン後デスクトップでブラックアウトしたままになります。

 

色々ググッてみるとsambaは更新により過去の設定ファイルが役に立たない場合があるという記述を発見。 このsambaを設定したのはCentOS6.4のとき。 今は更新により6.6となり、それからの自動更新が行われています。

ちょっと信じ難い部分もありますが、昨年末にアップデートし、安定稼動を見届けた状態のスナップショットもありますので問題の切り分けには丁度良かろうと…CentOS動作のサーバー(WEBサーバー / リバースプロキシ / MySQLサーバー / samba)を昨年末にロールバック。

 

今回一番うかつな作業でした。

 

MySQLのDBやWEB本体のディスクはすべてNFS経由で親サーバーのストレージにありますので、仮想サーバーには一切依存性のデータは残していないはずでした。

それは事実ですが、一点依存性のある重要なファクターを忘れていました。

 

時間です。

 

時間軸が昨年末に戻り各サーバーのntpd同期が完了しないうちにサービスを動作させたので、特にWordPressがMySQLにアクセスした際にパニックが発生。 インデックスデータの整合性が取れなくなるというトラブルに発展。

まさに泣きっ面に蜂です。

WordPressのDBまで飛ばして、この2ヶ月ほどのデータがDBアクセスできない状態とあっては再起不能になりそうです。

ただこちらの問題は幸いWordPressにインポートしていたデータベース管理用プラグイン“WP-DBManagerにリペア機能が搭載されていて、インデックスの不整合を何とか修復してくれました。こちらはかなり運が良かったです。(今回ノートパソコンでもロールバックして痛い目をみたので、今後ロールバックはよほどのことがない限りやらないと心に誓った)

 

しかし、まだsambaは不調のままです。 なんら不具合対策は前進していないです。

ここまでサーバーをあれこれ触っていたので、一度システム全体をリセットして仕切りなおし…と親サーバーを再起動すると、さらに別の問題が発生します。

 

つづく・・・

2015.02.24

サーバー不幸の連鎖

2月22日(日)よりサーバーが不調です(現在進行形)。

やっかいな状態なのと私がうかつな作業をしてしまった事でトラブルの連鎖という情けない状態になったので、備忘録もかねてblogに残します。

 

事の始まりはドメイン”wendy-net.jp”を登録しているマイドメイン社のDNSサーバー”ds.mydomain.jp”が22日お昼ごろからダウンしていたことに端を発します。

スマホ(docomo回線)から当サイトの動作をチェックしようとしてWEBが見えていないことに気がついて、原因を探ろうとノートパソコンを起動すると

 

ログイン後デスクトップ起動中に画面が真っ暗のままマウスカーソルが表示される

 

という状態に陥り起動がままならない状態となります。

 

「サーバーの様子がみたいのにその前にノートパソコンかよ・・・」と毒づきながらまずノートパソコンが起動できないの原因を探らねばなりません。

強制終了して再起動してもログインするとまったく駄目、復元ポイントを使用してロールバックしても駄目。

逆に復元ポイントに戻ったことによりアプリの整合性が取れなくなりアンインストールしたソフトが、「プログラムの機能」にエントリポイントだけ残して居座ってしまいアンインストールできなくなります。このためアプリによっては(例えばMicrochip社の開発ツール”MPLAB X”など)事前にアンインストールが前提のアップデートソフトがインストールできなくなるという余計なトラブルを抱えます。

こちらは“geek”というアンインストーラーの保存状態に関係なく問答無用にアンインストールするというアプリを使用することでノートパソコンの状態は一旦元に戻ります。

 

やっと、画面ブラックアウトの原因を探れると探っているあることに気がつきます。

「ネットワークが切断されているとデスクトップが起動する」ということに。

何度か再起動してもネットワークがOFFであれば、なにも問題なく起動します。

もしかしたら・・・とsambaに接続している共有ディスクにカーソルを触れて、クリックすると…反応が返ってきません。

どうやらサーバーのsambaが完全に停止ともいえない中途半端な動作をしているようです。

 

WEBサイトが動いていない原因(このときはまだ外部のDNSサーバーが原因とは気がついていない)を探ろうとしていたら、sambaも不調…

なにやらとても不幸な出来事が起こっている予感がします。

 

22日は日曜日。

我が家のサーバーは日曜日の朝5時にcronにより再起動するようになっています。

「再起動がトリガとなって一気に不具合が多発?」以前再起動によりRAIDディスクの不具合が勃発したこともありうネガティブな考えしか頭に浮かびません。

しかし、日曜朝の再起動でシステムからメールに自動送信してくるディスクの状態はなんら異常は示していません。

 

 

とりあえず共有ディスクの再起動時の接続を解除することでサーバー本体とノートパソコンが安定してつながる状態が確保できたので、まずは原因の究明から入ろうと作業開始。

でもそれは不幸の連鎖のまだ入り口でした… つづく・・・

 

本来は↓のネタを書きたかったのに・・・