ただのにっき。

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

11ページ目 (40ページ中)

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

2016年3月22日 / / 0件のコメント

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

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

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

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

BB.exciteが速くなった…？

2016年3月10日 / / 0件のコメント

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

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

Verisignのpublic DNS

2016年1月29日 / / 0件のコメント

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

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

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

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

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

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

2016年1月29日 / / 3件のコメント

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

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

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

2016年1月28日 / / 0件のコメント

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

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

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

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

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

2016年1月25日 / / 0件のコメント

どうやら、日産が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=”サイバー・クライム”]

Buffaloの「BSKBU13」は予想以上にコンパクトだった(汗)

2015年11月25日 / / 0件のコメント

自宅ではレノボのThinkPadキーボードを愛用していたのだが、気がついたらEnterキーの辺りがおかしくなってしまった。具体的には、Enterキーを押下しても数回に一回くらいの頻度でしか効いてくれないという、なかなか切ない状況。というわけで、代替キーボードを探してみたのだが、とりあえず小さいものであればいいやってことで、Amazonで安売りしていたこともあってBuffaloの「BSKBU13」を買ってみた。

…届いてみると、確かにコンパクトなのだが、キーピッチ(キートップのサイズ)が小さすぎた。普通の…というか、よく見るキーボードは19mmちかくだが、「BSKBU13」は17mm。単純に小さい。普通のキートップのサイズになれてしまっているとどうも打ち間違えてしまう(まぁ、慣れでなんとかなる世界はかなりあるんだろうとは思うけど…)

あと、なかなかツラいのはEnterキーが小さい。どうしてもコンパクトキーボードは無理矢理に詰め込んでいるので、必然的にしわ寄せはフツーのキーボードだと割と大きなEnterキーに来てしまう。要するにEnterキーが小さいのだ。Enterキーが小さいとどうなるかというと、本人はEnterキーを押下しているつもりなのだが、気がついたら閉じかっこ(」)を入力してしまっていることが多い。TeraTermだと、コマンドを入力して実行するつもりでブラケットを入力してしまうことになるので、これはなかなか切ない。

こればっかりはちゃんと確認しなかった私が悪いので、「BSKBU13」のことはすぱっと忘れることにして、次はサンワサプライの「SKB-SL18BK」を試してみることにした(これもAmazonde安く販売されているので、なかなかドキドキするけれど…)キーピッチも19mmだし、多少はEnterキーも大きそうだ。はてさて、私のキーボードはどうなることやら。ただ、買い直して、結局、2台のキーボードを買うことになっても、総額ではレノボのThinkPadキーボードを買うよりは安く上がりそうなので、サンワサプライの「SKB-SL18BK」がイイ感じなら良しとしたい。

[amazonjs asin=”B013D22XN8″ locale=”JP” title=”iBUFFALO 有線コンパクト&スリムキーボード ブラック BSKBU13BK”]

CentOS7のNTPサーバ/クライアント

2015年11月4日 / / 0件のコメント

CentOS7から、ntpdに代わって(…という割にはntpdも普通に使えるんだけども)chronyがNTPクライアント/サーバになったらしい。ntpdが普通に使えていたので、chronyの存在しならないままだったけど、ひょんなことからchronyの存在に気付いた…。

というわけで、備忘メモ。

インストールするとき

普通にCentOSをインストールするとchronyもインストールされてそうだけど、最低限のインストールを行うと入ってないこともあるようだ。

sudo yum install chrony

chronydの設定ファイル

CentOS7だと、/etc/chrony.confが設定ファイル。NTPサーバを指定する書き方はntpd.confとよく似ているけど、微妙に違う(そりゃ当然だ)

OS起動時に起動する/起動する

ま、普通にsystemctlに御願いする。

sudo systemctl enable chronyd

sudo systemctl start chronyd

NTPサーバとの同期状況の確認

以下のコマンドで概況を知ることが出来そう。今、同期に使っているサーバとズレを確認するコマンドはこんな感じ。

chronyc tracking

んで、ソースに指定しているNTPサーバとの通信状況を確認するには、こっちのコマンド。

chronyc sources

まぁ、こういうのも慣れなので、今度、CentOS7を使うことがあればntodではなくchronydを使ってみることにしよう。

[amazonjs asin=”4798043591″ locale=”JP” title=”CentOS7で作るネットワークサーバ構築ガイド (Network server construction gu)”]

WordPressのメモリー使用量上限値はデフォルトで256MBだった。

2015年9月30日 / / 1件のコメント

運用しているWordPressが吐き出すPHPのログに「PHP Fatal error: Allowed memory size of 268435456 bytes exhausted」みたいなエラーが出ていた。これが出ていたときには、管理画面が真っ白になっていた(遠い目)まぁ、256MBもメモリーを食ってる処理をどうにかしなきゃいけないとは思うけど、とりあえず、上限値を押し上げてみて動くようなら、それで乗り切ってしまおう…と思った(ま、ヒマが出来たら調べてみようかと)

何にも考えずにphp.iniをいじって「memory_limit = 512M」としてhttpdを再起動(Apache httpdとmod_phpで動いてる)を再起動してみたが、やはりどこかでメモリー制限がかかっているようで、php.iniの設定が有効にならない。で、仕方ないのでWordPressのソースコードを読んでみたり、プラグインのソースをチェックしたりぐぐってみたりしているうちに、「WP_MAX_MEMORY_LIMIT」って定数の存在に気がついた。→詳細はこちら

要するに、WordPressはデフォルトでメモリー使用量上限値を設定していて、そのデフォルトが256MBらしい。普通は、この上限値で問題ないと言われれば確かにそうだろうなぁと思うが、php.iniで設定しても反映されなかったときはプラグインのどれかで設定しているのかなぁ…と調べてしまった(All in One SEO Packは制限値を変更できる機能がありそうだったが、デフォルトは256MBだった)

というわけで、wp-config.phpにて「define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ );」と追記したら、メモリーを使い切った系のエラーは出力されなくなった。とりあえず、一件落着ということで…原因調査はそのうちに…。

nginxがHTTP/2に対応したらしいので…

2015年9月25日 / / 0件のコメント

どうやらnginx1.9.5でHTTP/2に対応したらしい。→「Nginx 1.9.5登場 – HTTP/2モジュール搭載」

このサイトのnginxをバージョンアップするついでにHTTP/2に対応させてみた。このサイトではSPDYに対応させていたので、まずはnginxのconfigureオプションから「–with-http_spdy_module」を削除した(nginx1.9.5からSPDYモジュールは削除されたらしいので)。その上で、オプションに「–with-http_v2_module」を追加。あとのオプションはそのままでビルドしてみた。

nginx1.9.5をインストールして再起動する前に、nginx.confを修正。spdyを有効にしてあったが、もうSPDYモジュールはいないのでspdyの記載を削除して、代わりにhttp2を追加した。

listen 443 default spdy ssl;
↓
listen 443 default http2 ssl;

あとは、nginxを再起動してみたら、HTTP/2が有効になっていた…はずだがブラウザで表示させただけではわからないので、Chromeに「HTTP/2 and SPDY indicator」ってChrome拡張をインストールしてみたら、アドレスバーの脇にブルーの稲妻が表示されていたのでHTTP/2で通信しているんだろうってことで。…なんかWordPressのレスポンスが早くなった気がするようなしないような…(遠い目)

追記：
nginxのバージョンアップをした後で、nginxの「ngx_http_v2_module」モジュールのページを見てみると、パラメータがいくつか設定できるらしいので、あとで設定を追加してみようかなぁと。

«過去の 投稿 新しい 投稿 »

© 2025 ただのにっき。

Theme by Anders Noren — 上へ ↑