‘ノウハウ’ タグのついている投稿


環境

iPhone5
iOS 8.4.1
他の環境はチェックしていない。

現象

audioタグで音声を再生させるテストページを作成。以下のようなざっくりシンプルなソースを書いた。

<audio src="./test.mp3" id="sound"></audio>
<p id="play">PLAY</p>

<script>
$("#play").click(function(){
  document.getElementById("sound").play();
});
</script>

PLAYをタップしたらtest.mp3が再生される仕組みなのだけど、どうしても音が出ない。PCのブラウザでアクセスした場合は問題なく再生される。

間違った方向に悩む

これはmp3のエンコードがおかしくて音が出ないのでは無いか?という見当違いなことを考えてビットレートを変えてみたり、ステレオをモノラルにしてみたり、mp3をwavにしてみたりと試したのだが状況は変わらず。もちろんすべてPCでは再生される。
WEBサーバのMIME設定が漏れてるかな?と思いいじってみるも、元々PCでは再生されているわけでそんなはずもなく。

BASIC認証が足かせだった

なんかおかしいなあ、ということで試しに別サーバに置いたmp3を指定してみたら再生された。別サーバなので、環境は全然違うのだけど、これはBASIC認証なんじゃないか?ということに気付き、試しにBASIC認証外にソース一式持って行ったらあっさり動いた。

iOS関係のバグみたいだが

そもそもBASIC認証下でmp3再生するような要求は、公開前のテストサイトくらいなものなので、まあそういう不具合あっても仕方がないですよね、レアケースですよね、なんて思った次第。
ざっと検索すると似たような事例がiOSのバグとしてあるようだけど、いつまでたってもBASIC認証を記憶するようにならないMobile Safariに、多くを期待しても仕方がないのでは、という風に考えている。


ちょいちょい話題に出るものの、現実的なケースに滅多に遭遇しないので、気づいたタイミングでのメモ。

巷には色々なブラウザがある。IE、FireFox、Chrome、Opera、Safariなどが代表的なものだ。IEは悪名が轟きすぎてMacユーザにも知られている一方で、SafariはMacユーザは知っていてもWindowsユーザが必ずしも知っているわけでは無い。
で、実はSafari、昔はWindows用も出てましたよ、という話で、今はもう新しいのが出てないのですが、新しくなる前の最終バージョンが脆弱性あるままなのです、という事実。なんだかんだIE8はいまだにパッチが出たりしているのに。

JVN#42676559 Safari においてリモートからローカルファイルを読み取り可能な脆弱性

http://jvn.jp/jp/JVN42676559/

公開日が2012年10月23日。3年近く前だ。その段階で

2012年10月23日現在、Windows 版 Safari 6.0.1 は公開されていません。Windows 版 Safari のユーザは使用を停止してください。

つまり使うなと言われております、という状況。それでもWindows用Safariの表示対応を要求しますか?なんていう話がまれに出たりする。

でも、もうきっと遭遇しないだろうな。そうであることを祈る。


すっかり忘れておりました

WEBサイトをガラケーでアクセスした場合、UserAgentで判別して、ガラケー用サイトにリダイレクトするように設定して運用していました。
URLを打ち込んでの動作は問題無いのですが、ツイッターにURLを書き込んだ場合、リンクを踏むとPC用サイトを無理やり表示したような画面になっているという連絡が。
過去にも似た事例あったなあ、ということで小一時間ばかり数年前の記憶を辿っていました。人はすぐに忘れてしまうものです。

Googleの変換なのでGoogleに聞こう

「PC用サイトを無理やり表示したような画面」というのはGoogleの変換サービスだということは、すぐに思い出しました。実際アクセスログを調べてもそのタイミングでのガラケーのUserAgentは見つからないので、直接アクセスが無いのは明白です。
Googleが変換しているんだから、Googleが情報を出しているだろう、ということで調べてみました。

ありました。というか思い出しました

あー、これこれ。というものでした。

携帯端末での表示について
https://support.google.com/webmasters/answer/35312

ページのheader部分に1行記述するものでした。

<link rel="alternate" media="handheld" href="ガラケー用ページ" />

本当に綺麗さっぱり忘れていました。

ノウハウの蓄積も必要とされてこそ

わざわざ今更書くような事柄では無いのかも知れないけれど、実際自分が忘れていて、あれえなんだっけ?という風に思ったりするわけで、必要とされている間は誰かが情報を出し続けないといけないかな、なんてことを考えました。
フィーチャーフォンの新規サービスは先細り、というか、先細りももう無いくらいな現状ですが、それでも定期的にメンテナンスが発生する案件などもあるわけです。

もしこのタイミングで同じ問題にぶつかってここに来た人がいたら、ちょっとだけ嬉しいです。


先日、Ustream配信のお手伝いをしました。
直前で連絡をいただき、丁度体が空いていたのと、そういう作業がここ最近ご無沙汰でしたのでかなり楽しかった。


Live streaming video by Ustream

会場はエイトビットカフェ

場所は、新宿三丁目のエイトビットカフェ。以前もイベントの配信をしたのだけど、その以前というのがネットブック全盛時だったので随分前。むしろまだUstream配信が活発に行われていなかったような時代で、ソーシャルストリームよりもチャットの方がコメントが多かった記憶がある。

今回は通常営業の店の奥を借りて半ば公開生中継という体裁をとった。

使った機材と仕組み

ノウハウになるかどうか分からないですが、そういう趣旨の記事なので。

配信は、映像と音声の2系統を別々のソースから持ってきて行った。

mac mini


配信に使ったマシン。

手持ちのノートPCにはライン入力どころかマイク入力もなかった。USBで外部入力できるようになるし、そういった機材はそんなに高価ではないけれど、今回用にそれを買うなら自前のmac miniを持って行こうとなった。

WEBカメラをUSBポートに接続し、音声は外部入力から引き込んだ。
配信のソフトは何も使わずChromeでUsetreamのダッシュボードを開き、配信した。

カメラのスイッチングだとか間に既に録画した映像だとか画像だとかを表示する場合、それなりのソフトが必要かもだけど、今回は1カメラ固定でずっと流すだけなので特別なことはしなかった。

WEBカメラ


LOGICOOLのC270。

MacOSの対応は書いていないけれど、それは付属ソフトのことのようで、USBポートに挿すだけで問題なく認識した。
音声は別系統なので、とりあえずちゃんと映ればヨシ、というレベルのカメラ。高画質配信はUstreamに課金しないとそもそも出来ないので、まぁこんなもの。

三脚


カメラの固定装置、実は結構重要。

特に今回のように引いて広い画面を撮る場合、思った以上に調整が入るし、「机の上に何かの箱を置いて……」というような場所にカメラを置けないことが多い。今回は最大で4人並んだ状態の映像を配信したので、距離にして3メートルは離れた場所にカメラを置いた。
ここは面倒臭がらずに三脚を持参。

三脚になんでもよいのでコンパクトデジカメを取り付け、コンデジ背面の液晶部分にWEBカメラをガムテープで固定する。WEBカメラは三脚に取り付けることを考えられておらず、USBケーブルに引っ張られることもあるので、固定するための台座としてコンデジを利用する。

これがこの記事でもっとも重要なノウハウ。

音声


お店の機材をまるまる借りた。

マイク2本、CD、ターンテーブルをDJミキサー経由で接続したALLEN&HEATHのミキサーからREC OUTで出してmac miniに繋いだ。RCAのステレオからミニピンのオーディオケーブルは持参した。パソコンは大抵ミニピンだ。

ミキサーの出音はお店のスピーカーからも鳴っているのでスピーカーで聞こえるバランスで配信されていた。あとはmac miniへの入力レベルが大き過ぎて音が割れてしまわないかだけをチェックした。

喋りの他に出演者のP.O.Pの曲をBGMにかけた。音楽をかけた人は普段DJもする人なのでその辺はなれたもの。

モニター

お店にあったモニターをmac miniに接続し、出演者に見えるように設置した。
これで自分が見切れているかを確認出来る。
演者の手元にノートPCを置いて実際のUstream配信を見て調整も可能だけど、それだとタイムラグがあるので、それと別に配信前の映像を見えるようにした。

要は配信内容

Ustreamは、P.O.Pというアーティストのリリースに関するもの。本人たちが話す1時間の番組。
さすがにステージをやっているアーティストなだけに話も上手いし、その場の雰囲気にのまれたりしない見事なものだった。
映像のスイッチングといった技術的なギミックはまったく出来なかったけれど、それで間が持つし、ちゃんと楽しめる内容に出来るというのは凄い。
身も蓋もないけれど、その部分は、いくらIT技術が進んだとしてもそんなに変わらなかったりする。

つまり、実はあんまり力にはなってないです、ということ。それでもここまで出来る。

番組終了後、ギャラとして番組中でサプライズをしたバースデーケーキと、ホットコーヒーをいただきました。ありがとうございました。


またもやニッチなノウハウ。

PC用URLを代表にして、mod_rewriteでUserAgent毎にページを振り分ける処理をしていました

RewriteCond %{HTTP_USER_AGENT} "KDDI" [NC,OR]

こういった記述でUserAgentで振り分けしていました。よくやる手法です。.htaccessなんかに書きます。

FacebookにPC用URLでシェア投稿しました

お知らせや宣伝でよくやりますね。スマホで見ても、UserAgentの振り分けでスマホ用ページに行ってくれるだろうという見込みです。

それが予期せぬページが表示されていました

うーん、謎ですね…ということで調査しました。

FacebookのスマホアプリだとUserAgent文字列が違いました

auのiPhone5の場合、こんな感じでした。

"Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 [FBAN/FBIOS;FBAV/14.0.0.25.26;FBBV/4017285;FBDV/iPhone5,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/7.1.2;FBSS/2; FBCR/KDDI;FBID/phone;FBLC/ja_JP;FBOP/5]"

お尻の方に、まんまとKDDIが入っていました。
それが原因でガラケーの判定に引っかかり、結果ガラケーページに飛ばされていました。
他キャリアはどうかなと思い、ログをみたところ、DoCoMoは「NTT DOCOMO」が入っていました。ソフトバンクは入ってない様子。

判定の順番は上からなので、先にスマホの判定をいれるように順番を変えて解決しました。やれやれ。

ガラケーの判定はうしろに

今もガラケーの手当しているサイトはそんなに多くないと考えるのですが、逆に言えばそういう所はガラケーの対応の後にスマホの対応をしてきた経緯がある可能性が高いです。
ということは、記述も先にガラケーの判定があり、その後にスマホの記述したケースが多いかも知れません。その場合は今回のようなトラブルにぶつかる可能性があります。
 

今回もレアケースな対応例でした。


シェアオフィス的な場所に作業場を持ちました

知り合いのミリメーターに声をかけてもらい、井の頭に作業場を作った。他にイラストレーターの方達等と一緒にフロアをシェアするような形式。

ネットワークはOCNの回線をシェアすることに

自分の使うネットワークはセキリティリスクを考えて分けさせて貰ったのだが、他の人達は共用のネットワークを使うことになった。OCNの1回線。
普通にNTTのブロードバンドルータから分岐して使えばいいのだけど、ここで問題が起きた。
集まったメンバー全員がMacユーザーで、ここに来るまではそれぞれAirMacでネットに接続していたということ。同時にTimeCapsuleでバックアップを取っているので環境が変わったからといって簡単に接続をやめることが出来ない。

最初はそれぞれAirMacからOCNに繋いでいました

最初はとりあえず繋がればそれでオーケーだったので、AirMacにOCNのアカウントを設定して、接続していた。NTTのブロードバンドルータは中継するだけの存在。それはそれでうまく運用できていたようだったのだけど、ここに追加で要望が出てきた。

ネットワーク上でレーザープリンターを共有したい

デザイナーの人で自前でカラーレーザーを持ち込んだ人がいた。今まではAirMacから有線で繋いで使っていた。自分だけで使うのであればそのやり方で問題ないのだけど、せっかくのシェアオフィスだし、共有して使えるようにしたいということになった。

ということで吉祥寺北口システムの出番

ちゃんとしたLANにしましょうということで簡単なネットワーク図を書いた。

複数のAirMacを持ち寄ったLANの構成

NTTのブロードバンドルータからOCNに接続するようにして、それ以下はすべて同じネットワーク上に配置するイメージ。DHCPはNTTのブロードバンドルータで実施。AirMacはブリッジモードで設定しなおした。

AirMacのブリッジモードがミソ

今回はそれぞれのAirMacの設定を変更しないとならないところがヤヤコシイ部分だった。
AirMacは個人持ちの機材で、普段は設定をいじるようなものではないので、そもそもブリッジモードって何?な状態。こちらとしては普段AirMacを触らないのでブリッジモードなんてモードがあるんですね…という感触なわけで、そこの部分がちょっとだけ敷居が高かった。分かってしまえば設定は簡単で、つまりは慣れの問題。

複数のAirMacを使ったLANの構築というケースは実際どのくらいあるのか分からない。いわゆるオフィスで無線LANを構築するといっても席の数だけアクセスポイント作るなんてことは普通しないわけで、TimeCapsuleがある分、AirMacの台数が増えるパターンがあるのだなぁという感想。

ちなみに自分のネットワークは完全に分離されています

設定した割に自分はそのネットワークに参加しない。Windowsマシンなので仲間はずれになっている、とかでは無く、通信環境を一緒にしてしまうことで
・トラフィックを圧迫したくない
・ネットワーク的な問題が起きた時の切り分けをハッキリさせたい
・ウィルスなどの影響を出さない/受けない
という点で分離させてもらった。ネットワーク無いと仕事が成立しないし、それで各方面に迷惑はかけらないので自前で用意します、ということ。


2013年はWEBサイトそのものの面倒を見る機会が何度かあり、その中でサイトにつながりにくくなるという現象に遭遇した。
出来るだけそうならないよう心がけてはいるものの、そうなってしまったのは自分に原因が無くても申し訳ない気持ちになる。

ネットなどでつながらない報告がある時
「光の100メガプランだけどダメ」
といった書き込みを見かけたりする。それでもダメな時は100%無理だったりするけれど、多くの人はそこまでは知らないよねぇ、と思うことがあるので大まかに原因をまとめてみた。

サーバ負荷が高い

重いスクリプトを実行してサーバそのものが重くなっている場合。

例えばスクリプトの中で無限ループが起きればいつまでたってもレスポンスが返ってこないし、そこまで単純なことで無くてもデータベースへの問い合わせが遅いとか、ロジックが複雑で時間がかかるとか、インターネットで無くても手元のPCでだってよく起きている現象。
WEBサーバの場合はそれが複数同時に起きているので負荷が上がり出すと他の処理も巻き込まれてどんどん重くなってしまうケースが多い。

思い切ってapacheを再起動すると瞬間的に軽くなるが、また同じパターンで重くなることが殆どなので、それで嵐が過ぎるのを待つといった消極的な対応をすることもある。

解決策としてはスクリプトの軽量化や負荷が高くなるボトルネックの対応、サーバを増やしてロードバランシングするなど、色々な手法があり、システム屋として一番頑張れるところではある。
ただし実際起きてしまうと即対応がなかなか出来ないという針のむしろを味わうことになる。

負荷試験を行うという場合は大抵はこの負荷を測って改善する作業を想定する。

サーバのネットワーク負荷が高い

インターネットからサーバまでの回線速度はサーバによって様々で、たとえば「さくらのVPS」では、共有100Mbpsで接続されている。ざっくりな理屈の上では「光の100メガ」の人が一人サーバにガッツリ接続して通信してれば他からの通信は割り込めない状態になる。そうなれば他の人達がいくら速い回線でも繋がらない。

現実にはそこまでネットワークが専有される状況というのは滅多に無いのかもしれないけれど、スペックそのものが良くなっていくにつれて通信出来る量も増えていっているので、昔からの感覚があるのであれば、きっとそれよりは起きやすい。

もっとも簡単に起きるケースに巨大ファイルのダウンロード公開がある。
100Mbpsの回線で50MBのファイルを公開して3人が同時にダウンロードしはじめたら…ということを想像すると分かりやすい。単純計算で考えればもう一杯だ。

ちなみにネットワークが原因でつながらない場合はサーバ負荷は比例して高くなるということは無い。50MBファイルのダウンロードであれば頑張っているのはapacheのプロセス3つだけでしかないし、やっているのはバイナリのレスポンスなだけだ。

CDNといったコンテンツの分散がもっとも簡単な対策だけど、利用するにはお金がかかるわけで、その費用が必要であることを説明して理解してもらうには、現状ではまだそれなりの努力が必要だと思われる。

サーバのネットワークまで届いていない

DNSが参照できなかったりでサーバの名前解決ができない場合や、モバイル環境などで通信トラフィックが混んでいてそもそもインターネットまでちゃんと繋がっていない場合。サーバ側には来てないので状況が全然分からないので解決がなかなか難しい。

「光の100メガ」といった、クライアント側の回線の話ではあるのだけど、それぞれのクライアントで状況が違うので、実はもっとも厄介ではある。ただし、そういった報告やクレームが正式にくることは稀で、コミュニケーション出来る相手であればtracerouteしてもらうなんて手段で個別に解決は出来る。


無料枠でテスト的に使うとして

AWSは、業務で使うことはあるけれど、テスト的に導入するといった場合にどれだけ気軽に出来るのか?ということは考えたことはなかった。制限があるし、その制限が無いことがAWSを使う利点でもあるという意識があったからだ。
とはいえそこで否定するのもアレなので、もし無料利用する場合にはどんな条件なのかをメモしてみた。

参照元は クラウドサービス 無料利用枠のご案内 | アマゾン ウェブ サービス(AWS 日本語) で、2013年11月17日現在の情報なので、あくまで参考までに。

前提として利用期間は12ヶ月間でさらに月内の利用時間に上限がある

AWS新規申込みのユーザーに対してのサービスで12ヶ月間の提供となっている。1年無料ということ。
さらに以下の制限がある。

月750時間というのは、24時間×30=720時間なのでEC2を1台起動しっぱなしで問題ないと判断出来る。複数台の場合は起動しっぱしは出来ない。AWSの柔軟な部分は切り捨てて1台のレンタルサーバと考えれば問題ないとは言える。

データ転送が15GB/月なので、大きめのファイルやトラフィックの多い場合には注意が必要だ。ソフトバンクのテザリングが7GB/月を超えると速度低下が発生するということなので、15GB/月というのもそこまで余裕のある数字では無いのかもしれないが、そもそも論でそんなにスペックの高いサービスでは無いことを考えると、高トラフィックでデータ転送量が跳ね上がる恐れはそこまで無いかも知れない。そんなに心配ならばチェックしよう、ということだとは思う。

1台のレンタルサーバとしてのスペック

EC2で使えるインスタンスはマイクロインスタンス。マイクロインスタンスのスペックはインスタンスタイプを参照すると以下のようになっている。

AWSの考え方前提なので他のレンタルサーバと比較するのは簡単では無いけれど、乱暴にまとめると

というVPSサーバ1台に相当する。さくらのVPSの1Gよりも低いスペックだと判断しても良いと思われる。

経験上、メモリが1GB無いとapache+phpだけでも物理メモリを圧迫する。mysqlをRDSに外出しするにしてもリソースギリギリの構成だと想像できる。
980円/月のプランより低い、期間限定の無料プランだと考えれば仕方の無い内容だとは思うけれど、そこまでしてAWSを使う理由は感触を確かめたりオペレーションの学習といった理由以外ではあまり利点は無いのではと考える。

セットアップの手間などはどこまで一般的に想定されているのか分からないのですが

これは他のVPSやクラウドでも言えることだけれど、セットアップは自前で行う必要がある。
この部分、自分では感覚がズレていることだけは分かっているのだけど 通常サーバを借りる=必要なシステムは用意出来ている という感覚であるならばAWSではもう一手間、しかも今まで知らなかったような作業が発生することになる。
今はネットで検索すれば、セットアップ方法もそれなりにあるだろうし、それの練習だと思えば問題ないけれど、無料のレンタルサーバのサービスだと考えてしまうとハマってしまうのでは無いかと思われる。

apache設定中の凡ミス

2013年9月15日

あいかわらずのあるある話。

ssl.conf の設定をいじっておりました

apacheが動いているサーバでssl.confをいじっておりました。
場所はお決まりの /etc/httpd/conf.d/ssl.conf です。

なんとなくオリジナルを退避しておきたくなりました

ファイルを弄る前になんとなくオリジナルを退避しておこうと思ってしまい

# cp ssl.conf ssl.org.conf

とオリジナルをコピーしました。設定終わったら消せばいいや、的な感覚です。

案の定apacheが起動しなくなりました

ssl.confを無事編集完了して、さてさてapache再起動

# service httpd start
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:443
                                                           [  OK  ]

あれあれ?おかしなメッセージが出るなぁ、どこか間違えたかなぁ?でもOKって出るなぁ、なんて思ってブラウザでアクセスするもつながらない。

# ps ax | grep httpd
25156 pts/0    S+     0:00 grep httpd

OK出てるけど実際にはhttpdのプロセスはあがってない状態。

原因は明らかな凡ミス

原因はssl.org.confが同じconf.dディレクトリにあったから。apacheが起動時にどちらも読み込んでいるので、重複した設定があってエラーになっていた。ですよねー。

# rm ssl.org.conf
# service httpd start
Starting httpd:                                            [  OK  ]

ボヤッとしてると起こしてしまう恥ずかしい凡ミスの一例。


たまにボンヤリしてやってしまったり、運用はお任せな時に問合せを受けることがあるのでメモ。
次回お問い合わせを受けた際には参考までにということでURLをお送りできるし。

テンプレートエンジンは、テンプレートファイルでWEBページの更新をします

phpのsmartyなどのテンプレートエンジンでは、直接HTMLファイルを公開ディレクトリに置くのでは無く、規定の場所にテンプレートファイルを置くことでページを更新する。

テンプレート内にはルールに添って書かれたコードが一部入っているものの、概ねHTMLなので更新は比較的楽だし、システム寄りの知識が無くても、アンタッチャブルな部分、もしくは直すべき部分が認識出来るスキルさえあれば更新出来る。

ただしテンプレートエンジンは処理負荷があります

WEBサイトでページを表示する際、ただ単にHTMLのテキストを返すだけの処理にくらべて、テンプレートに沿って動的に文言を埋めたHTMLを返す方が、処理が発生する分、負荷がかかる。

その処理をなるべく軽くする為に、テンプレートエンジンのシステムではテンプレートから中間ファイルを作ってキャッシュする手法を取ることが多い。中間ファイルのキャッシュはテンプレートエンジンが扱い易い形式になっていて、人が見てわかりやすいテンプレートよりも処理量が少なくて済む。

もちろんその中間ファイルを作成するのにも負荷がかかるわけで、出来る限り中間ファイルのキャッシュを使いまわして負荷を減らすようになっている。

なのでテンプレートが更新されたかチェックされます

上記の理由から、テンプレートファイルが更新されたと判断されない限りはキャッシュが使われる。

そんな理由から起きる、ありがちなトラブル

今まであったテンプレートファイルを一旦退避して新しいのに上書きした後、やっぱり戻します、という場合に、退避したファイルを再度アップすると更新されない、というケースがある。

パニックになった感じで言えば「ファイルを元に戻したのに、元に戻らない!」という具合。

原因はファイルのタイムスタンプ

何故そういった現象が起きるかと言うと、テンプレートエンジンからはテンプレートファイルが更新されて無いように見えるから。

再度アップした退避ファイルのタイムスタンプが古いままだと、テンプレートエンジンは新しいファイルを上書きした際に作られたキャッシュを見てしまうので、元に戻しても無視された状態になる。

ファイルのタイムスタンプを新しくすることで解決

ファイルのタイムスタンプを上書きするファイルより新しくすることで、テンプレートエンジン側に更新があったと判断させることが出来る。

テンプレートエンジン側は、テンプレートの中身が変わろうが、元に戻ろうが、そんなのはお構いなしに手元で抑えているキャッシュのタイムスタンプと比べているだけの場合が多い。

なので、とにかく注意するべきはファイルのタイムスタンプだということ。分かってしまえば簡単なことだし、そんなに意識しなくたって良いのだけど、たまに忘れてあれあれ?なんてこともある。