ただつらつらと日記が書かれていくようです。

カテゴリー: ITめいたこと (9ページ目 (31ページ中))

mineoのsimで接続できないと思ったら、APN違い

mineoのSIMカードを申し込んだら、(当然だけど)普通に届いた。

申し込み完了からだと、だいたい3営業日くらいだろうか。しかし、ちょっと前のMVNOって、SIMカードを送ってくるのって宅急便だったような気がするけど、今回は普通の郵便だった。宅急便だと確実は確実なんだろうけど、受けとる手間があるし、料金もかかりそうだもんなぁ…。個人的には郵便で十分だと思う。

んで、大きめの封筒を開けると、SIMカードと接続案内の冊子が入っていた。mineoのdプランを申し込んだので、ドコモのロゴ入りのSIMカードが入ってるのかと思いきや、入っていたのは真っ白なSIMカード。これもまぁ、MVNOのSIMカードを申し込んだのに、ドコモのロゴ入りSIMカードだと「…あれ?」って思う人はいるかもしれないが、真っ白ってのもなぁ…なんてことを考えながら、Android端末にSIMカードを刺して起動するものの接続できない。

mineoのwebを見ながらやったはずなんだけどなぁと途方にくれつつ改めて設定を確認してたら、とあることに気がついた。

  • mineoのAプラン(auの無線網利用)と、Dプラン(ドコモの無線網利用)でAPNが違う。
  • APNがmineo.jpなのって、Aプラン。
  • DプランのAPNは、mineo-d.jp。

APNの指定が違ってたら接続できやしないのは当然か。とはいえ、接続するキャリアが違ってたら、同じAPNでもよさそうなもんだけどなぁ(…ダメなのかもしれないけど…)そして、なぜか、dプランのAPNの方だけに「-d」が付くんだよなぁ。

とりあえず、mineoのdプランのAPNは、mineo.jpではなくて、mineo-d.jpが正しいってことは覚えておこう。

WordPressのサイトが真っ白…。

WordPressで構築してある別サイトにログインしようとしたら、画面が真っ白。さらに、どのURLにアクセスしても真っ白…。しかも、httpのステータスコードとしては503を返しているけど、phpのエラーログには何も出てないし。

…というわけで、全くもって何がどうなっているのかわからなかったけれど、まぁ、とりあえずプラグインから疑ってみるとかと言うことで、SSHでサーバにログインして、wp-contentのpluginsディレクトリの下にある、プラグインのディレクトリをとりあえずmvして名前を変えて、アクセスしてみた。すると、「jetpack」をリネームしたら、普通にWordPressの各画面が表示されるようになったので、まぁ、これはAutomatticが公開しているjetpackプラグイン。ちょっと調べて見たら、jetpackプラグインのchangeログにこんな記載があった。

どうやら、jetpackのVer.4.0.2が2016年4月21日にリリースされていて、Ver.4.0が抱えていたバグが修正されたらしい。

Bug Fix:
Addresses an issue where Jetpack 4.0 caused a fatal error on sites with specific configurations.

specific configurationsってなんだろう…と思ったが、とりあえず、JetPackのバグでWordPressが真っ白になっていたようだ。specific configurationsという条件があるおかげで大騒ぎにはなってなさそうだけど、このバグを踏んじゃった人は割と慌てるんじゃないかなぁと…(遠い目)ま、それに4.0より古いバージョンだと問題なさそうなので、ピンポイントでVer.4.0をインストールした人となると、まぁまぁ少ないか。

エックスサーバーのバックボーンって。

エックスサーバーというレンタルサーバ屋さんがある。どうも、WordPressを動かしたいみなさんに人気らしく、そんなWordPressを動かしたい友人がエックスサーバーでレンタルサーバを借りたから動かして欲しいとのこと。…てか、そんなの自分でなんとかしろよとも思ったんだけど、一応、手を貸すことにした。

ファイルを転送している間にエックスサーバーについて調べてみたら、エックスサーバのサーバ群は、どうやら、さくらインターネット方面のネットワークに置いてあるようだ。んで、WordPress専用のレンタルサーバーサービスのサイトにはこんなことを書いてあった。

全サーバー共セキュリティ完備の国内データセンターで管理し、232Gbpsの大容量バックボーンに2Gbpsという高速ネットワークで直結しています。

まー、結局、エックスサーバーが買っている帯域幅が2Gbps(とはいえ、共用の1Gbpsのネットワークを2本引き込んで、冗長化って感じじゃないかなぁ)ってわけだから、この大容量バックボーンの232Gbpsってのにどれくらいの意味があるのかはよくわからない(普通、2Gbpsの帯域幅を売ってくれる人たちは2Gbps以上の帯域幅確保してるだろうし、他のユーザーへの提供も行っているんだろうし…)けども、これって、2010年頃のさくらインターネットのバックボーンの数字のような気がする。バックボーンの数字をアピールするのであれば、この辺の数字も更新した方がいいような気がするけどなぁ。さくらインターネットのサイトのページによれば、とりあえず、2016年4月現在、712Gbpsらしい。ざっと3倍くらいにはなっているし、IXである、JPIXへの接続は2010年当時で9Gbpsだったのが、2016年だと100Gbpsまで帯域幅が増えている。

さくらインターネットがこれだけバックボーンを太くしてきているってことは、石狩以外のデータセンターのラックも売れ行きも好調だろうなぁ。

…と、どうでもいいことを書いているうちにファイルの転送が終わるだろうと思っていたら、まだ終わらない…。

TwitterのAPIにアクセスするアプリケーションが止まった。

Twitterにアクセスするアプリケーションは、アクセスしたいアカウントにログインして、APIでアクセスするためのOAuthのアクセストークンを発行してもらうことになっている。ところが、最近、この手続きのためにアプリケーションを登録するための前提条件として、アクセスしたいアカウントの設定画面の「モバイル」の欄にSMSを受け取ることができるケータイ番号を登録し、TwitterからのSMSを受信し、そこに書いてある認証コード入力するという作業が必要になったようだ。つまり、ケータイ番号を登録しないとアプリケーションの登録ができないような仕様変更がなされたようだ。

この仕様変更までに登録してあったアプリケーションについてはどうなるのかなんてことも考えることもなかったのだが、TwitterのAPIにアクセスしているアプリケーションが落ちたので調べて見ると、アクセスTokenが無効になっていた。…お、おぅ。ケータイ番号を登録しないとAPIにアクセスさせないというポリシーは、過去に登録されたアプリケーションに対しても有効で、バサッとTokenを無効にされたらしい。

ただ、ケータイ番号を登録してないけれど、同じようにアクセスしている別アカウントのTokenは、同じタイミングで無効になっておらず、もしかすると、アカウント毎にバサッとTokenが無効になるタイミングが違うかもしれない。このアカウントにも、一応、ケータイ番号を登録してSMSで認証しておいたので、Tokenの無効化は回避できるかもしれないと期待はしているが、twitter10周年で思わぬ仕打ちを受けたような気がする。

そして、だいたいこういうのは、かなり前に告知されていたりするもので、それに気付いていない開発者が悪いというオチになるんだろうけども…いやはや。一応、Twitterの開発者向けブログを見てみたが、それっぽい記載を見つけられなかった。うーむ(遠い目)

BB.exciteが速くなった…?

先日、試しにBB.exciteを契約してみたけど、いざPPPoEのセッションを張ってみると、なんとなーく遅い。tracerouteしてみると、割と近いところ、例えば、地域IP網からインターネットに抜けるあたりが混んでる雰囲気…。とあるサーバーへのpingのRTTが大きめ。

とりあえず、ここが混んでると、どう頑張ってもダメだろうなぁ。しかしまぁ、月額500円のサービスだし、こんなもんかなぁと思ってたけど、3月3日にメンテナンスが行われたらしい。久々にルーターの設定を変えてBB.exciteに接続してみたら、先日とは大違いで、快適になっていた。とあるサーバーへのRTTもすっきり小さくなっていた。…やはり、3月3日のメンテナンスでネットワークが増速されたということだろうか。すばらしい。

Verisignのpublic DNS

どこかのblogで見つけたんだけど、Verisignがいつの間にかPublic DNSを公開していたらしい。試しに、ちょっと問い合わせてみた感じだと国内にサーバがなさそうな感じ。うーむ。

ちょっと前のGoogleのPublic DNSみたいな感じだろうか。全く根拠はないんだけど、アメリカの西海岸か中西部あたりの問い合わせてるような雰囲気。ちょっと遅い。国内にサーバが設置されたら、使い勝手が良くなるんだけどなぁ。普段使いするにはISPのリゾルバで十分な雰囲気かなぁ。

そういえば、VerisignのWebページにはこんなことが書いてあった。

他のほとんどのDNSサービスとは異なり、ベリサインではプライバシーを尊重します。パブリックDNSデータを第三者に販売したり、広告提供を目的としてクエリをリダイレクトしたりすることはありません。

との記載が。ふむ。public dnsを提供してるみなさんはそういうビジネスモデルなのね。

HTL22の認証情報ストレージのパスワードは罠だろうなぁ

auのAndroid端末のHTL22(HTC製)にVPNのアカウントを設定しようとすると、”認証情報ストレージのパスワード”を要求された。…この端末で、そんなパスワードを設定した記憶がない。というか、認証情報ストレージってなんなんだろうなぁ。

仕方ないので、ネットで調べて見ると、どうやら画面ロックの方式の中に「パスワード」があって、そのパスワードが認証情報ストレージのパスワードとして設定されるらしい。普段はパターンを入力してロックを外しているので、パスワードは設定がされてないはずだ。というわけで、一旦、パスワード入力でロックを外す設定にしてパスワードを設定したあとで、パターンに戻した。そしたら、VPNの設定ができた。うーむ、HTL22の場合、ロック解除用のパスワードが認証情報ストレージのパスワードになるのか…。そんなの知らんがなと思いつつ、もしかするとこれも何かの勉強になったのだろうか、いやはや。

iOS版のChromeをアップデートしたらデータセーバーが使えなくなってた

うーむ、iPadにインストールしてあるChromeにアップデートが出ていたので、普通にアップデートをかけて起動してみたら、「データセーバーのサポートが終了しました」的なメッセージが出てきた。WiFiルーターなんかに接続しているときには、データセーバーで通信量が削減できるのは良かったんだけども…。

どうやら、フレームワークの変更

で、調べて見ると、TechCrunchに、このアップデートに関する記事が載ってた。どうやら、iOS8から採用されたけど、しばらく使いづらかったWKWebViewってフレームワークがiOS9で使えるようになったので切り替えたらしい。この変更により、iOS版のChromeの安定性が増しただけでなく、JavaScriptの実行速度も改善したらしい。

しかしまぁ、iOS上で利用するフレームワークが変わったことでデータセーバーがサポートされなくなったとしても、安定性の向上とJavaScriptの実行速度の向上とのトレードオフと言われると、ま、仕方ないかという気もしなくもないが、一方で、データセーバーの中身(例えば、画像プロキシでの画像データの圧縮とか、PageSpeedによる最適化とか、GoogleのサーバとChromeの間でSPDYを使うとか)を思い出してみると、なんとかならないものだろうかという気もしないでもないなぁ…。そのうち、しれっと復活してくれることを願いつつ…。

日産がDDoSを食らったそうで。

どうやら、日産がWebサイトにDDoSを仕掛けられて、その結果、しばらくWebサイトを止めていたらしい。とりあえず、アノニマスが犯行声明を出していたらしいけども…。しかしまぁ、捕鯨やイルカ漁に対する抗議って事で日産がDDoSを食らったということは、アノニマスのみなさんがご存じくらいの大企業にとっては、何らかのDDoS対策を施さなきゃいけないという危機感が生まれたんだろうなぁと。

とりあえず、復旧後の日産のWebサイトのIPアドレスで引いてみたらdefence.netのIPアドレスが返ってきたので、日産は、急遽、DDoS対策ソリューションを導入したんだろう。で、一方、同業他社のマツダのWebサイトのURLを引っ張ってみたら、普通にELBのアドレスが返ってきたので、Akamaiとかdefence.netのように、CDNっぽいネットワークでトラフィックを受け止めるタイプのDDoSソリューションも、そう浸透しているわけでもないのかもしれない。

ま、そういう感じの世の中になりつつあるということで、defence.netの創業者のBarrett LyonのDDoSとの戦いを描いた「Fatal System Error」の日本語訳の「サイバークライム」でも読み直しておこうか。

[amazonjs asin=”B00APR9E00″ locale=”JP” title=”サイバー・クライム”]

« Older posts Newer posts »