Fedora 11 on hp mini(無線LANとWillcom)
ぜんぜん更新されないhp miniのLinuxディストリビューション「MIE」に不安を覚えたのと、ネットブック風デスクトップやharbour-launcherが気に入らなかったので、Fedoraに戻ることにした。
インストールはいたって簡単で、liveusb-creatorを利用してUSBメモリにイメージを作成して、USBスロットに挿してからf9キーを押しながら起動、デスクトップに表示されるインストーラのアイコンから普通にインストール作業を進める。
ここまではいいのだが、それですべてというわけにはいかない。一番困ったのが、デフォルト状態では無線LANがうんともすんともいわないこと。
# lspci -v|grep Network 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 0
Broadcom社のBCM4312という製品を動作させる必要があるようだ。RPM Fusionにこれに対応したドライバがあるので以下の要領でyumで追加できるようにした。
# su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \ http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm' # yum install broadcom-wl
ところが、インストール時のカーネル2.6.29だと問題なく動作するのに、yum updateでカーネルを更新してしまうと動作しなかった。いろいろ調べてみたが、結局ここで見つけた手順に従い/etc/modprobe.d以下の適当なところで
# yum install wl-kmod # echo "install ssb /sbin/modprobe wl;/sbin/modprobe --ignore-install ssb" >> /etc/modprobe.d/dist-oss.conf
として再起動したところ、無事に動作した。
それから、外出先でWillcomのUSBモデムNS001U(netIndex)を使いたかったのでこちらも設定したが、特に難しいこともなく、普通に「システム」→「管理」→「ネットワーク」から新しいハードウェアとして一般的なモデムを選択し、USBモデムが/dev/ttyACM0として認識されていたのでモデムデバイスとして指定、それからデバイスとしてプロバイダ情報にあれこれ書き込み、「Willcom」として保存すると、/etc/sysconfig/network-scripts以下にifcfg-willcomというファイルが出来上がっていて、/etc/ppp/peers/willcomもさっくり用意されるので、あとは
# ifup willcom
で接続できた。めでたしめでたし。
Popularity: 2% [?]
キャリア別インライン画像付きHTMLメールの正しい書式
仕事でいわゆるデコメール、アレンジメール、ようするに携帯向けHTMLメールを送信するプログラムを作成することになり、いろいろ悩んだので同じことになる人がいないようにメモしておく。
docomoには仕様書があるが他のキャリアにはなかったので、ほとんど勘で作業することになった。困ったポイントは(1)auのcidは@の数と書式に制限がある(2)SoftBankはboundary文字列の長さに変な制限があること。
HTMLメールに関しては、各キャリアともガラパゴスといわれるのも仕方がない仕様だと思う。外部の画像ファイルの読み込みを制限する必要があるのは理解できるが、それでもマルチパートのメールとしての書式くらいは守ってほしいものだ。
とりあえずいくつかの端末で動作したので公開しておく。今後不具合が見つかった場合に改修するかもしれない。
改行は全てCRLFとする。 【】内はフォーマットではなく フォーマットの詳細。
docomo
MIME-Version: 1.0 FROM: me@example.com Subject: 【mime encodeしたJIS文字列】 TO: you@example.com Content-Type: multipart/related; boundary="------------boundary1" Content-Transfer-Encoding: 7bit --------------boundary1 Content-Type: multipart/alternative; boundary="------------boundary2" Content-Transfer-Encoding: 7bit --------------boundary2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 【mime encodeしたJIS文字列】 --------------boundary2 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable 【quoted printableにエンコードしたJISのHTML】 (画像は<IMG src="cid:0@0">のような書式になる) --------------boundary2-- --------------boundary1 ←複数の画像がある場合はここから画像データまでを繰り返す Content-Type: image/gif; name="【mime encodeしたJIS文字列】.gif" Content-Transfer-Encoding: base64 Content-ID: <0@0> 【base64_encodeしてchunk_splitした画像データ】 --------------boundary1--
au
MIME-Version: 1.0 FROM: me@example.com Subject: 【mime encodeしたJIS文字列】 TO: you@example.com Content-Type: multipart/mixed; boundary="------------boundary1" --------------15b49b545 Content-Type: multipart/alternative; boundary="------------boundary2" --------------boundary2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 【mime encodeしたJIS文字列】 --------------boundary2 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable 【quoted printableにエンコードしたJISのHTML】 (画像は<IMG src="cid:0@0">のような書式になる) --------------boundary2-- --------------boundary1 ←複数の画像がある場合はここから画像データまでを繰り返す Content-Type: image/gif; name="【mime encodeしたJIS文字列】.gif" Content-Disposition: attachment; filename="【mime encodeしたJIS文字列】.gif" Content-Transfer-Encoding: base64 Content-ID: <0@0> ←必ず「数字@数字」とする 【base64_encodeしてchunk_splitした画像データ】 --------------boundary1--
SoftBank
MIME-Version: 1.0
FROM: me@example.com
Subject: 【mime encodeしたJIS文字列】
TO: you@example.com
Content-Type: multipart/related;
boundary="------------boundary1" ←21文字にする必要がある
--------------boundary1
Content-Type: multipart/alternative;
boundary="------------boundary2" ←21文字にする必要がある
--------------boundary2
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
【mime encodeしたJIS文字列】
--------------boundary2
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable
【quoted printableにエンコードしたJISのHTML】
(画像は<IMG src="cid:0@0">のような書式になる)
--------------boundary2--
--------------boundary1 ←複数の画像がある場合はここから画像データまでを繰り返す
Content-Type: image/gif; name="【mime encodeしたJIS文字列】.gif"
Content-Disposition: inline;filename="【mime encodeしたJIS文字列】.gif"
Content-Transfer-Encoding: base64
Content-ID: <0@0>
【base64_encodeしてchunk_splitした画像データ】
--------------boundary1--
途中PHPの関数名が出てきているが、気にしない。あと、PHPでquoted printableにするのにはimap_8bit関数を使った。
Popularity: 6% [?]
hp mini + mie + Willcom(NS001U)
WillcomのUSBモデムNS001U(netIndex)がhp mini用UbuntuであるMIEで使えた。
本体にNS001Uを差し込んでdmesgを開くと、期待したようにttyUSB0ではなくttyACM0として認識されていた。
# dmesg | grep tty ..... [ 84.975909] cdc_acm 1-1:1.0: ttyACM0: USB ACM device ....
そこで、ダイアルアップ接続用の設定ファイルを作成する。
# cp -a /etc/ppp/peers/provider /etc/ppp/peers/willcom
で、このファイルの中身を下のように変更する。
# vi /etc/ppp/peers/willcom .... #connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T ********" connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T 0000000000##64" # Serial device to which the modem is connected. #/dev/modem /dev/ttyACM0 # Speed of the serial line. #115200 460800 user "your-willcom-user-name" ....
スピードの設定は何が最適なのかよくわからないので適当。「connect」はWillcomを利用するときの電話番号、「user」はユーザ名となる。そしたら
$ sudo pon willcom
これで接続に成功した。
Popularity: 6% [?]
WILLCOMのスパボ一括
WILLCOMがスーパーボーナス一括払いみたいなことを始めている。2年間の月額料金が980円とのことだが、機種代金を一括で支払ってしまったら月額料金はもっと下がってしまう。
Popularity: 2% [?]
携帯電話向けサイトのセキュリティ
以前、こんなことを書いたわけだが、最近ちょっと毛色の違う携帯サイトへの攻撃が増えているのでメモ。
携帯電話の強みとして、マイクロペイメントの仕組みが充実しているという点がある。ようするに、従量課金で100円のコンテンツを売る場合、PC向けサイトだとクレジット決済で手数料がコンテンツの価格の半分近くになったりしてなんとも不合理だが、携帯電話の料金として徴収してしまうシステムだと100円のものは(ほぼ)100円で買えるわけで、その点で携帯電話は非常に強力なプラットフォームだ。しかも、契約情報と関連した端末固有のIDがサーバに送信され蓄積されるシステムのため、それが犯罪に対して一定の抑止力となっている。
それをふまえて、先のエントリではたかだか月額315円のサイトをだまくらかしても得られる利益はたかが知れているというようなことを書いていた。しかし、昨今では例えばアフィリエイトと組み合わせて、大量の契約済端末で月額課金サービルスに登録してアフィリエイトサイトから大量の見返りを得ておいて、支払い前に振り込め詐欺用の使い捨て電話として端末を売却し、アフィリエイトの見返りのみを手にしてドロンというケースが相当な件数で発生しているようだ。アフィリエイト会社に成果発生して料金を支払うコンテンツ提供会社は、キャリアからの支払い情報に大量の「支払い不能」契約を発見するが、支払い情報を手にすることができるのがそもそも何ヶ月か後だったりするので、成果発生して得られるはずの料金を手にすることが出来ず、かといってアフィリエイト会社にその分を請求することもままならない状況に陥ってしまう。
確かにこの不景気で支払い不能による料金未回収が増えたとはいえ、上のようなパターンの詐欺も見過ごせない程度の規模になりつつあるようだ。
Popularity: 1% [?]
携帯サイトばかり作っているとセキュリティ意識が下がる
暴論ではあるが、実際にそういう事例を見てきたので、ちょっと書きとめておく。
PC向けサイトは、あらゆる攻撃にさらされている。攻撃用スクリプトの実行も非常に簡単で、HTMLのソースには誰でもアクセスできる。URLバーもあって、GETの値を書き換えてみるくらいのことは当たり前に出来る。しかし、携帯サイトでは、以下のような事情もあり、それほどセキュリティについては真剣に対応しなくてもなんとかなってしまう現状がある。
■攻撃者を選ぶサービスである
携帯向けサービスの場合、サイトへのアクセス経路が必ずキャリアのゲートウェイになるので、意図しないアクセスを全てブロックするのは簡単だ。だから、攻撃者はどこかの踏み台サーバからの匿名的なアクセスではなく、何らかの契約情報にひもづけられたアクセスであることを余儀なくされる(パケットの改ざんレベルはここでは問わない)。公式サイトであれば、端末固有のIDが送信されてしまうので、なおさら匿名性は低い。
もちろん、世の中にはありとあらゆる手段で自分の持ち物以外の携帯を手にしている人もいるだろうし、嘘の情報で契約されたものもあるだろう。だが、そんなものを手にしている人たちが、せこせこと月額315円の携帯サイトを攻撃することなどあまり考えられない。普通は、もっと重大な悪事に使うだろう。
したがって、たいていのユーザが容易に自分の身元が割れそうな状態でサイトにアクセスしていることになるので、それほどひどい悪事が行われる可能性はPCと比較するとかなり少ない。
■攻撃が難しいデバイス
どこかで拾った携帯、あるいはとなりの人のをちょっと失敬した端末で攻撃を企てる人がいるとしよう。DoCoMoの携帯だから現在アクセスしているURLを表示できる!喜び勇んで眺めてみると、そこにはどうやら個人情報にひもづくらしいキーと値がセットされている。では、ここを改ざんして他人に成り済ましてみよう!
ところが、PCサイトであればブルートフォース攻撃などちょっとしたスクリプトで簡単にできるのに、アクセス制限のかかった携帯サイトが相手の場合、あの世界的に有名な打ちにくいボタンでせこせこ入力する以外には、ほとんど手段がない。よって、微笑ましいほどの数のパターンしか試すことができないのだ。なんとか工夫したところで、やっぱりたかが知れている。大人数でやればいいのかもしれないが、人を集めるコストと、人数が増えることによる秘密の漏えいリスクを考えると、やっぱり割が合わない。
■Javascriptが使えない
もちろん一部の端末では使えるのだが、基本的にフルブラウザ(TM)でない限りは携帯サイトではJavascriptは利用されない。したがって、Javascriptを起点としたXSSなどの攻撃が意味をなさない。もちろん、サービスの管理画面などPC側の画面では問題になるだろうが、逆にいえばここだけ抑えればなんとかなってしまう。
もちろん、以上の理由から携帯サイトのセキュリティなど無意味だ、というのは間違った考え方ではある。それに、実際には携帯独自のセキュリティホールだって(NDAの壁があって世の中には出回っていないが)当然存在しているので、セキュアなサービスを作るのが一概にPCより楽だというつもりはまったくない。だが、PCの世界では当たり前のように対策していたことが、携帯サイトばかり作っているとついついおろそかになってしまう傾向は絶対にあると思う。
最近、作成中のサービスで某ベンダのセキュリティ診断を受けたのだが、事前対策中に上のようなことを強く思わせる問題がいくつもあった。昔はこんなんじゃなかったのになあ、というのが開発者たちの感想だった。そう、昔はこんなんじゃなかったのだ。HTMLのソースも見られない環境に慣れてしまうと、単純な攻撃に対する意識はどんどん薄れていってしまうのだ。気をつけよう。
Popularity: 2% [?]
HEADリクエストとLocationの小ネタ
PHPでLocationヘッダを出力してリダイレクト処理をするとき、
<?php
header("Location: http://www.example.com/");
exit;
?>
こんな感じでリクエストを普通にリダイレクトで飛ばすのが大半なわけだが、このリクエストがHEADで来た場合、リダイレクト先へのリクエストも当然ながらHEADになってしまう。
携帯サイトでOBJECTタグを使った場合、auなどはダウンロードページのOBJECTタグのURLに記述された先へHEADリクエストが飛ばされる(ことがある)。そこでOKが返らないとちゃんと動作しない。いつも飛ぶわけではなさそうなので、キャッシュの問題もあるのかもしれないが再現性があんまりなくて深追いしていない。
で、たとえばセッションで認証していたりする場合、$_SERVERのREQUEST_METHODを参照してHEADリクエストの場合は別処理にしてやるなどしないと、OBJECTタグでアクセスする先のファイルで認証エラーが発生したらログインページにリダイレクトで飛ばそうなんて処理を入れたら、HEADリクエストのままリダイレクトされてしまうので正常に動作しない。
しかし、それはそれでHEADリクエストを使って認証をかいくぐる方法なんかが考案されたらまずい。とはいえ、
$_SERVER['REQUEST_METHOD'] = 'GET';
とかやってももちろんLocationヘッダでリダイレクトしたらHEADリクエストのまま飛んでいってしまう。
というわけで、OBJECTタグでアクセスする先のファイルで認証を入れたい場合は、失敗したらいっそ404を返してファイルが存在しない、とかしてやった方がいい。少なくともHEADリクエストのままどこかに飛んでいってページが正常に表示されなくなるよりはまし。
Popularity: 2% [?]
iPhoneのSIMカードはSoftBank 3G端末では認識しない、けど…
SoftBankのサポートページのPDFファイルにはこんな記述がある。
・専用USIMカードはSoftBank3Gに挿しても使用することはできません。
・SoftBank3Gへ戻す場合には、USIMカード交換(有償)が必要となります。
確かに実機で検証するとこんなエラー画面になる。
ここまではSoftBankの説明どおりである。
実にけしからん。iPhoneなんかやめた、と思い切って他の端末を友達から安く買ったという人はいったいどうすればいいのか。消費者の見地からこれは実に見過ごせない由々しき問題である。
ところで、SoftBankといえばその前身はVodafoneである。
SoftBank3Gではだめだというなら、ではVodafoneならどうなのだろう。誰もがそんなことを思うことには疑いの余地はない。
というわけでさっそく実験。iPhone 3GのUSIMカードを取り出して適当なVodafone 3Gの端末に入れて起動してみる。
起動した。となりの黒い箱は犠牲となったiPhone。
起動しただけかもしれないのでさっそく電話する。
通話できた。
ちなみにSIMロックが解除されたヤクザな携帯端末もちゃんと起動する。
もちろん、iPhone 3GのSIMロックを解除したわけではないので、念のため。第一、iPhone 3G専用をうたっているあのSIMカードは、そもそもiPhone 3Gを買った人じゃないと手に入らないので、何かの犯罪を教唆しているわけでもない。
あ、パケット通信はできないよ。
あと、番外編としての豆知識。
1 iPhone3Gは電源が入ったままSIMカードを抜いても大丈夫だった。
2 SIMカードをドックの口に挿す人間は必ずいる。
3 iPhone 3GとかSIMロック解除とかいうキーワードはすさまじくSEO効果が高い。
何かを勘違いしてアクセスしてきた人たちにはサービス画像。
iPhone実機が買えなかったので想像して描いたiPhone。
Popularity: 100% [?]
SoftBankのメールサーバ移設でミスが起きてないか?
近頃どうも奇妙な現象が続いていたのだが、どうやらSoftBankがメールサーバの集約に失敗し続けているようだ。
いつからかはまだはっきりしないのだが、この2ヶ月ほど、何度か突然vodafone.ne.jp宛のメールが送信エラーになることがあり、どうしたのかといぶかっていたのだが、昨日その瞬間を捉えることに成功した。手元にスクリーンショットなどはないのだが、まとめるとこんな感じ。
- 突然@t.vodafone.ne.jp宛のメールが送信エラーで戻ってくる。
- ログをみると途中でリレーを拒否されたといっている。
- telnetで25番に接続してみる
- 某レジストラのサーバに挨拶される(びっくり!)
というわけで、digでいろいろ調べていたが、1時間くらいでIPアドレスが変わって復旧していた。最初は自分のところのネットワークがSoftBankから蹴られているのかと焦り、次はDNSポイズニングかと思ってさらに焦ったが、telnetしたらさらにびっくりした。きっとその某レジストラは、大量のリレー要求がきてびっくりしていたはずだ。
ちなみにいまdigしてみると
$ dig MX t.vodafone.ne.jp ; <<>> DiG 9.2.4 <<>> MX t.vodafone.ne.jp ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35439 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;t.vodafone.ne.jp. IN MX ;; ANSWER SECTION: t.vodafone.ne.jp. 783 IN MX 10 mx.k.vodafone.ne.jp. ;; ADDITIONAL SECTION: mx.k.vodafone.ne.jp. 300 IN A 202.179.204.119 ;; Query time: 7 msec ;; SERVER: 202.224.32.1#53(202.224.32.1) ;; WHEN: Wed Jul 9 19:35:24 2008 ;; MSG SIZE rcvd: 71
こんな感じになっている。
Vodafoneのメールアドレスは東京なら「t」みたいに分かれていたのだが、現在は「k」を向いているらしい。おそらくもともとの母数が少ない上にみんなsoftbank.ne.jpにメールアドレスを変更しているところなので、メールサーバを集約しているのだろう。
まあ、それはいいとして、ttlが短いのがすごく気になる。普通、クライアントの数も相当なものだから、キャリアのMXレコードなんてそれなりの長さに設定しているはずだ。大丈夫なんだろうか。
今回の件は、おそらく旧メールサーバを廃止してどこかに統合する際に、IPアドレスが変更になる場合は普通は旧サーバを残して単純に新サーバにリレーするようにしてくれればいいだけなのを、一気に切り替えてしまって、DNS情報の更新が浸透する前に旧サーバが消えてなくなってしまった状態になったのだろう。で、宛先不明のIPアドレスについては一定期間までレジストラがキープしてくれているだろうから、そっちを向いてしまっていたといったところか。
いずれにせよ間抜けな話だし、おまけに少なくともこの1、2ヶ月くらいは同じミスをちょこちょこやっていそうなので、なおさらひどいものである。
Popularity: 2% [?]
携帯端末の404 Not found対策
携帯端末の場合、サーバからステータスコード404が返ると、サーバ側のエラー画面を表示するのではなく処理を中断してしまうことがある(少なくともauではそうなった)ので、.htaccessでの制御で工夫しなければいけない。
普通、ステータスコード別に表示するHTMLドキュメントを指定する場合は
ErrorDocument 404 /error.html
のようにErrorDocumentディレクティブを利用する。しかし、ここで指定するのがローカルファイルへのパスの場合、ステータスコードはそのまま404を返してしまうため、携帯端末だとページを表示する前に処理が中断され、指定したドキュメントを表示させることができない。
解決方法は簡単で、
ErrorDocument 404 http://selfkleptomaniac.org/error.html
のようにリモートのURLを指定すると、この場合は404ではなくリダイレクトの302が返るため、携帯でも問題なく表示することができる。Apacheのマニュアルでは
リモート URL (例えば、頭に http と付与した方法) を ErrorDocument に指定するとき、 たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、 Apache はリダイレクトをクライアントに送出するということに、注意してください。 これにはいろいろと関連して起こる問題があります。 中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、 代わりにリダイレクトのステータスコードを受け取るということです。 これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする ウェブロボットやその他クライアントを、混乱させるかもしれません。 さらに、ErrorDocument 401 にリモートの URL を指定すると、 クライアントは 401 というステータスコードを受け取らないため、 パスワードをユーザーに入力要求しなければならないことがわかりません。 従って、ErrorDocument 401 というディレクティブを使う場合は、 必ずローカルな文書を参照しなければなりません。
とのこと。
Popularity: 3% [?]





