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


環境

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="ガラケー用ページ" />

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

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

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

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


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

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

ネットワークは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を返す方が、処理が発生する分、負荷がかかる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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


日記代わりにつけているブログを、さらにfacebookにリンクをシェアしている。
いままではOGP設定していなくても本文中の画像を拾ってサムネイルにしてくれていたのが、ここ最近うまく拾ってくれないので、ざっくりOGPを吐き出すようにした。

そういうプラグインもあると思うのですが

自分用のブログで、管理をスマートに分かりやすく、という風なこともなく、分かれば良いレベルなので、カスタムフィールドに直接書いたものをテンプレートに吐き出すことにする。
やることは、ページのタイトルや本文とほぼ同じ。

こういうこと。

テンプレートをちょっと直す

header.phpを直す。直したところは以下のところ。

<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?> xmlns:og="http://ogp.me/ns#">

<!-- OGP対応で追加 -->
<?php
$image       = get_post_meta( $post->ID, "IMG", true);
$description = get_post_meta( $post->ID, "DESC", true);
if($image) {
?>
>meta property="og:image" content="<?php echo $image; ?>">
<meta property="og:title" content="<?php wp_title( '|', true, 'right' );echo "都市文化生活"; ?>">
<meta property="og:url" content="<?php echo the_permalink();?>">
<meta property="og:description" content="<?php echo $description;?>">
<?php
}
?>

なんてことは無い、カスタムフィールドのOGPデータがあったら、それにそってOGPのヘッダーを出力しますよというもの。


開発あるあるネタ。

テスト環境なのでDNS登録していないサーバ名でアクセスしたい

開発中のテスト環境なので、わざわざDNSにサーバ名を登録したりせず、手元でささっとやってしまいたい。そんな時はアクセスするPCのhostsファイルを設定して使う。

名前解決という仕組み

PCでインターネット接続する際にはサーバ名からIPアドレスに変換した上でIPアドレスのサーバに通信を実施する。その名前解決の順序は、hosts→DNS問合せ の順番で行われる。なので、hostsに書くことでDNSへ問合せしないでも名前解決が出来るようになるという仕組み。

hostsファイルは極々簡単なテキストファイル

ファイルの内容はいたってシンプル。

IPアドレス サーバ名

の羅列。IPアドレスとサーバ名の間に入るスペースは何個でも良い。もちろん半角。#以降はコメントとして無視される。空行も無視。
ルールはこれだけ。

例えば

192.168.100.101 hogehoge.mybenjo.net
192.168.100.102 hogehoge2.mybenjo.net

なんて具合。

最近のWindowsだとちょっと編集が面倒

hostsは、LinuxやMacだと /etc/hosts にある。管理者アカウントで編集する。すごくシンプル。

Windowsは、C:\windows\system32\drivers\etc\hosts にある。Windows95からずっと変わっていない。
Windows7(Vistaからかも?)以降では、スタートメニューでメモ帳を右クリックで選択して「管理者として実行」で開いて、そこからhostsファイルを開いて編集する必要がある。手順が少し厄介。

携帯電話やスマートフォンでは、出来ないと考えた方が良い。

これはセキュリティとあんまり関係ありません

テスト環境などで、広くみんなに見てもらう必要がない場合に簡単に済ませる手段として有効だけれど、この手順を踏まえれば、IPアドレスとサーバ名のペアが分かってしまえば誰でも出来る。なのでこれでセキュリティを確保出来ると考えるのは危険。
「テスト環境ということは、test.mybenjo.net で、www.mybenjo.net と同じIPアドレスで運用しているのでは無いか」という推測は突飛なものでは無いし、実際そういうことをするケースもありえるだろう。
あくまで一つの手法だ。