uso8000k.net

あっ、今日IPv6の日じゃないですか！登録後からあっという間ですね・・・なんとも今日確認する限りだと、登録済みJapanese登録は96。わりと知るものから、個人のところまで。・・・なんともuso8000kの場違い感が凄いです。さて、何を観測しましょうね。後ろでipv6トラフィックは見ているが、何を見ましょうね。

そういえば、ハリケーンネズミのトンネルブローカー (he.netの意) は安定しているのだけど、LinodeのIPv6付与サービスは実は安定していなかったりする。気を抜くとリンクローカルアドレスのみになっていてアレ。IPv6 Forumでのuso8000kのステータスはHTTPメンテ失敗となっているのですが・・・の問題ってひょっとするとこれが原因かもしれないですね。

先日のIPv6 Forumと同時に登録を行ったWorld IPv6 Launchの登録も反映した事を確認。これでアクセス数もUPというものです。

ところで、05/10の時点で登録総数が1454で日本だけに絞ると19って･･･これから増えるのだろうか。一応世界的な動きなのにちょっと寂しい感じ。増えるとイイナ。

むしゃくしゃしましたのでIPv6 Forum IPv6 Enabled Programに登録しました。これまでuso8000k.netを自主的にどこかへ登録するようなことはありませんでしたので、今回が初めてになります。技術的なことをしてはいませんが、折角対応してますので・・・来る06月06日 World IPv6 Launchの日もありますし、もう少しIPv6を使ってみようかと思います。まずはアクセスを受けないとですね。

しかし、登録してもらえるIPv6Readyのロゴを貼るスクリプトがW3C XHTML1.1に準拠していなく憤怒。修正。

<div id=ipv6_enabled_www_test_logo></div>
<script language="JavaScript" type="text/javascript">
var Ipv6_Js_Server = (("https:" == document.location.protocol) ? "https://" : "http://");
document.write(unescape("%3Cscript src='" + Ipv6_Js_Server + 
"www.ipv6forum.com/ipv6_enabled/sa/SA1.php?id=2995' type='text/javascript'%3E%3C/script%3E"));
</script>

<object id="ipv6_enabled_www_test_logo">
<script type="text/javascript">
var Ipv6_Js_Server = (("https:" == document.location.protocol) ? "https://" : "http://");
document.write(unescape("%3Cscript src='" + Ipv6_Js_Server + 
"www.ipv6forum.com/ipv6_enabled/sa/SA1.php?id=2995' type='text/javascript'%3E%3C/script%3E"));
</script>
</object>

∩( ・ω・)∩

最近、クラウドストレージのBoxが個人的にとても便利で仕方がありません。Webの管理ツールでファイルの同期なりアップロードができるオンライン無料ストレージサービスは数あれど、BOXはソレに加え、提供するWebインターフェイスを使用せずにWebDAVをそのままでマウントできるのはとても素敵です。つまりは一般的な方法でストレージをマウントができるということ。何も必要としないでWindowsのExplorerからもネットワークドライブが作れてしまうから素敵である。

私のVPSの容量は20GBです。先日購入したSK17aからBOXを登録すると、なんと通常5GBがもらえるところ、10倍の50GBが無料で使えます。・・・さて、こんな状況でこの容量、スマートフォン以外からも使わない手は無いですねぇ。

URL : https://www.box.net/dav
USER: [発行したBoxアカウント]
PASS: [Boxパスワード]

Boxにてアカウントを発行後マウント作業。

$ sudo emerge net-fs/davfs2
...
$ useradd -u [UID] -g [GID] -s /sbin/nologin davfs2
$ echo "http://www.box.net/dav [User] [Pass]" >> /etc/davfs2/secrets
$ mount -t davfs https://www.box.net/dav /mnt/box 

とりあえず、これで50GB増えました。ヤッター。ただ、オンラインストレージである事、そして1ファイル25MBまでということは留意。多分、Web型の2chリーダのログ、もしくはmhtによるWebアーカイブ書き出し場所にするとかなり捗ると思われる。

先日のVirtualhost関連で一つApacheの動作確認。Webブラウザから入力するアドレスをIPアドレスの16進にて入力した場合とソレを元にVirtualhostを設定した場合どうなるのか、気になるので試してみた。ちなみにココのIPアドレスは173.230.147.180。これを16進にするとADE693B4。それぞれのオクテット(8bit区切り) を16進に変換してドットを省いて、先頭に0xをつければ、一般的なWebブラウザはアクセスが可能になる。ということで以下のように設定を書いてみた

<Virtualhost *:80>
...
</Virtualhost>
...
<Virtualhost *:80>
ServerName 0xADE693B4
...
</Virtualhost>

通った。∩（・ω・）∩ばんじゃーい。名前解決周りの環境を整えなくても十分Virtualhostのテストはできる模様。しかし、SSLのVirtualhostをこの例の名前をグローバルIP直接指定しているという屁理屈と設定をもうひと捻りすれば、Virtualhostのアクセスさせることができないだろうか・・・HTTPヘッダ見たらHOST情報送っているみたいなのできませんよね。

通ってないわ！ばっかもーん！(追記:20100310) 10進側表示をキャッシュしてました。クリアしたつもりがクリアしていなかったのだ・・・ 16進と同じ表示結果が出ました。アクセスするにしてもVirtualhostの書き方にしてもどちらも16進も10進も変わらない模様。むしろ設定として明記した16進が優先で表示されているような。・・・そういえばIPv4の表記方法って、あくまでわれわれが認識しやすいように10進で書いていますよね・・・そういうことなのだろう。

Apacheを使いながら複数のドメイン名のSSL証明書を用意する場合、もう一つIPアドレスが必要とよく言われる。しかしネットワーク資源的にも、やはりSSLは何とか使いまわせるととても嬉しい。さて、この件について何が駄目で問題になっているか。HTTPのサービスをVirtualhostにて提供する場合には

NameVirtualhost hogehoge:80
<Virtualhost hogehoge.com:80>
...
</Virtualhost>
...
NameVirtualhost foofoo.com:80
<Virtualhost foofoo.com:80>
...
</Virtualhost>

と書く。通常のHTTP (ポート80番指定) の場合にはこのように。HTTPS (ポート443番指定) 指定の場合には一応Virtualhostの機能は機能しそうに思う。が、できない。理由は名前ベースにてVirtualhostディレクティブを記述した場合には、振り分けに使うHTTPのHOSTヘッダが取得できずに振り分けをすることができない。そのため、Virtualhostディレクティブ内の情報は無視されてしまう。HTTPSのVirtualhostを提供する場合にはIPアドレス指定にて記述する事となり、新規のIPアドレスが必要になる。

NameVirtualhost 192.168.0.1:443
<Virtualhost 192.168.0.1:443>
...
</Virtualhost>
...
NameVirtualhost 192.168.0.2:443
<Virtualhost 192.168.0.2:443>
...
</Virtualhost>

このように書く事となる。因みに、

NameVirtualHost *:443
<Virtualhost *:443>
ServerName hogehoge.com
...
</Virtualhost>
...
<Virtualhost *:443>
ServerName foofoo.com
...
</Virtualhost>

で、いけなくはない。ただし、Virtualhostのディレクティブ内に設定した証明書はApacheにて最初に指定された証明書を使う。恐らくは後者のホスト名についてはこの例のfoofoo.comにて正常なアクセスが出来なくなる(証明書エラー)。これが正常なSSLアクセスを提供出来なくなるもう一つの理由。その為、複数のSSLを一つのIPで提供するのであれば、

<Virtualhost 192.168.0.1:443>
...
<Virtualhost>
...
<Virtualhost 192.168.0.1:444>
...
<Virtualhost>

のような、もはや当たり前の苦肉の策になる。そして、これは証明書のエラーこそ発生しないが、通常のブラウザでのアクセスの場合はポート指定が必要となりサービスを受けるユーザにはあまりよろしくない。今更このような話を書いて何が言いたいか。HTTPSを使用する際の一つのIPに対して証明書が一つの問題は、HTTPSの仕様によるホスト名からのApacheの証明書の切り替えが出来ない事と、同時に設定した場合には片方の証明書しか有効にならないことである。SSL証明書発行の際には名前だけしか見てはいない。しかし、Apacheの処理上、IP一つとどうしても絡んでしまうのだ。同僚とそのような話をして、結論はポート分けてしか提供ができないって事で収まりはしたが、HTTP同等の名前ベースでのVirtualhost分けを前提に会話するという超テキトウな説明をして猛省中。

折角、先日phpを入れたのでぼちぼちMediaWikiを入れてみる。備忘録にもなるし。

# USE="imagemagick postgres" emerge mediawiki

超簡単。しかしGentooが推すwebapp-configを使う事になる。

# webapp-config -I -d mediawiki mediawiki [mediawiki Version]

ある程度パッケージとそれらを上手く管理するツールであるとはいえ、Apacheをある程度カスタマイズしている身からすると、この方法はちょっと気持ち悪い。ただ、Stowと同じような扱いのツールなので、多数のPortageからのWebアプリを管理するときはApacheの設定も元に戻してして身を委ねてしまって良いのかもしれない。一応/usr/share/webapp/mediawikiに大元がインストールされていて、ここから/var/www/辺りに展開する模様。ここから自分で入れたほうが都合の良い人もいるかと思う。

さて、webapp-configを使うかはともかくとして、public上に見えるところに置けばWeb上からセットアップができる。超簡単。セットアップから出力されたLocalSettings.phpを/Mediawiki/に置いて完了。わー、まんまWikipediaだこれ。

ちなみにこれは個人の備忘録に使うことになるのだが、一人だと多機能すぎて辛い。そして、ブランチのWikipediaのシステムもそうだけれど、「新規項目(白紙)を追加する」ってアクションが全く無いのが辛い。標準では一回ごとに検索から調べて新規追加するか、記事にシステム内リンクを追加して新規追加をする方法をとっていて非常に分かりづらいし、まだるっこしい・・・最初の一歩踏み出すと使いやすいのですが。

さて、ひょんなことからPostfix+Cyrus-imapdをちょっと触ることになる。なんでも頼まれた事の内容は.forwardで自分が持っている外部メールアドレス宛と、サーバ内のメールボックス宛と両方に配送したいとのコトで。一般的なIMAPサーバのCourierやDovecotなどのMaildir/mbox形式の場合は

$ vim ~/.forward
~/Maildir
hoge@example.com

と書けば良い。しかし、Cyrusは触れてみて分かるメールボックスの特殊さよ。Maildir形式じゃない。・・・仕組みがちがうコト忘れていると地味に困る。話を聞いたとき.forwardに追記すればいいやと思ったが、配慮が足りなかった。どうしよう。

$ vim ~/.forward
\user
hoge@example.com

こうしてみた。Postfixに設定してあるCyrusの設定

$ less main.cf
~
mailbox_transport=lmtp:unix:/var/[hogehoge]/lmtp

を信じてみました。結果、配送成功。さてサーバ内のユーザへのローカル配送を行ったわけなのだが・・・Cyrus形式にしてもMaildir形式にしても、これでいいんじゃないかな・・・あえて~/Maildirと指定する必要がイマイチわからなくなってしまった。どうしてだろう・・・

止むを得ない事情が無い限り、私は自分が所有するサーバにPHPのインストールは行いません。派手なものを好まない故か使うアプリもそうそうありませんので・・・　しかし何かの拍子に運用することになったり、周りの脆弱性情報を集めると、大抵CGI周りで脆弱性を付かれるのはPHPの書かれ方ではなくPHPの言語仕様であったり、PHPで書かれた複数のパッケージが依存関係で排他状態になったり、マイナーバージョンアップと思ってアップデートをしたら動くべきものが動かなかったり。これらが積もり積もって、私怨となり、今に至るのが私。

さて、しかしこうも運用レベルで問題があるのにPHPが未だに撲滅されていないのが理解できない。うーん。やっぱり人が多いと滅びづらいのだろうか。とりあえず外でワンワン吼えてても仕方が無いので、せめてマイナーバージョンアップで変わる仕様確認のためにPHPの導入をしてみようと思う。

# USE="apache2" emerge -v php

# vim /etc/conf.d/apache2
APACHE2_OPTS=$APACHE2_OPTS " -D PHP5"

ある日から突然もう片方のインターネッツ (ipv6網) に繋がらなくなり、はや1ヶ月。その間、気が向いたときにLinodeが提供するXen用最新のカーネルに入れ替えたり、ip6tables -F なり、ip6tables -Xなり、インターフェイスの設定の書き直しなり、全パッケージのリビルド (emerge -e world) なりを行ったりはしましたが一向に直らない。Linodeのv6割り当てや電気ネズミのトンネル、もしくはこの組み合わせで問題があるのかな？と他の責任にして諦めモードに入っていました。

基本はwww.kame.net宛に疎通確認をしたり、自分が持つipv6アドレスに送る事はして失敗をしていました。ん？しかし後者のはループバックだよなと::1宛に送ったら案の定反応なし・・・完全にこっちのシステムだコレー！？tcpdumpすると送信だけはきっちり出来てるし。

原因の切り分けが甘すぎました。もっと調べる事はあったのだ、なんてこった。

解法:

> Chain INPUT (policy DROP)

orz

多分何かの拍子に繋がらなくて、Chainの基本ポリシを忘れてip6tables -F とか -X とかして放置していたのが問題。酷すぎる。

最近コンピュータでかちゃかちゃやったことについて書くにしても、霜月半ばよりプチ忙しかったりしてはい。何も書くことが無いんだな・・・SakuraのVPSもごろごろ寝かせるだけで何もしていなかったり。Postfixのセカンダリとかはかろうじで動いてはいるがそれだけ、なんとももったいない。

とりあえずある程度は落ち着いたので、何かしら出切るといいなぁ・・・いや、最近やりたいことをやりたいとしか言わず何もしていない気がする。散々、やりたいって言う間にやれと言う人間がコノザマよ。何かしましょうね。いや、しろ。ごめんなさい。

しかし、この筆不精っぷり、月記レベルです。

マイクロソフトのエンジニア直伝! 5 mins トラブルシューティング 5 分動画で解決

こういう品質の高いサポートをある程度無償で提供してくれるMSが私は好きだ。

ＭＳパワーポイント劇場。

たまにこういう品質の高いギャグを無償で提供してくれるMSが私は好きだ。

無料と言うか、皆様のライセンス料に支えられているのですけどね・・・でもこういう支払いがあるからこそ受けられる製品使用権と、その後のいろいろなサポートなのかな？と思います。

ひょんなことから壊れたWindows2003Serverを触る。ありがたやありがたや。しかし、サーバの管理をまとめる「サーバ構成」のメニューが纏まっているhtaとおぼしきスクリプトが動かなくて、その先の構成の変更ウィザードを開けなくて困ったり。

答えを書いてしまうと

> cys.exe

をファイル名に指定して実行に入力して起動するとサーバの役割なりを追加するウィザードが立ち上がるのだが・・・このcys.exeって、"Configure Your Server" の略らしい(タスクマネージャより)。なんて名前だ。

某VPSの認証のユーザIDがIPアドレスである事に驚きを隠せない。認証側でブルートフォースの対策すればいいじゃないとは言われるけれど、それはどこか詭弁と思う。勘合札の片方を何故わざわざ分かりやすくするかね・・・折角伏せられているのに。ユーザ名も知られないことに越した事ないでしょう。少なくとも有効なアクセスを減らす努力にはなると思うのだけどなぁ。

個人的には辞書アタックが少し有効になるだけではなく、色々推測して入力できる余地があるところがあまり気に入らない。その辺り自分で任意のユーザ名を決められるか、Mixiの自分のメアドを使う (いずれもサービスには表示しない) ってのは悪くないと思うのだけどねぇ・・・ﾅｽﾞｪﾀﾞ。何故そうならないのだろう。やはり、不特定の人からの辞書アタックなり推測して入力されるということ自体が大して脅威ではないという事だろうか。

っと、つらつら書いてはみましたがメールや、Webホスティングのアカウント、皆、そうではじゃないか・・・つまりは気にするだけ無駄って事ですね。 結局はユーザのある程度のパスワードに関するリテラシと、開発側の対策なのでしょう。ソレゆえの認証側が対応すれば大丈夫、か。

・・・しかし、百歩譲ってもやっぱりIPアドレスは正直キモい。ネットワークの契約変わったらどうするんだろ。ユーザの任意のID変更ではないし、変更もできないから。これは無いと思うのだけどなぁ・・・迂闊にIPv4辞めますとかアドレス範囲変えますとか言えません。