このblogのアクセス解析を見たいので自宅サーバにawstatsを入れた。備忘録がわりに入れ方を書いておこう。

先ず、Awstatのオフィシャルサイトからawstats-6.2.tgzを拾ってくる。現時点で、最新の安定バージョンは6.2。これを解凍。

tar zxvf awstats-6.2.tgz

次に、解凍されたフォルダの中にある"wwwroot"というフォルダの中身を、httpでアクセスできる場所に移す。ぼくのサーバだったらこんな感じ。ところでawstatsを使うには、解析結果のHTMLを作らせてそれにアクセスする方法と、awstatsを直接CGIとして実行する方法がある。前者の方法でやるならこのコピーは不要。後者でやったほうがなにかと楽なので、ぼくのサーバでは後者の方法でインストールした。

cd ./awstats-6.2/wwwroot
cp ./* /home/httpd/html/ -r

awstatsの本体は"cgi-bin"フォルダの中に入っている。ここにある"awstats.model.conf"というファイルが設定の雛形。これをそのまま使ってもいいけど、複製したものに手を入れるのがお作法かな。"awstats.conf"ってのがawstatsがデフォルトで読みに行く設定ファイルの名前になっているので、その名前でコピーしてやる。

cp awstats.model.conf awstats.conf

そうしたら"awstats.conf"を弄る。かなり大きなファイルで設定項目も多いが、最低限、次の４つだけ弄れば動く状態になる。

• LogFile……解析したいアクセスログの所在を。Fedora Core 2なら/var/log/httpd/access_logがデフォルトになっていたとおもう
• SiteDomain……awstatsを動かすサイトのドメインを。
• DirCgi……awstatsの存在するフォルダ名を。ドメインの直下からのパスで指定する。たとえばhttp://blog.windy.ac/awstats/で動かしたければ、ここには"/awstats"と入れる。
• DirIcons……同様に、アイコンファイルの存在するフォルダ名を。"wwwroot"の下にある"icons"とかいうフォルダがそれ。

awstatsの本体は"awstats.pl"というperlで書かれたスクリプトだ。Webサーバの設定によるが、これをCGIとして扱ってくれないなら、.htaccessを使ってオプションを指定してやるのが手っ取り早い。拡張子を.cgiに変えるとかその辺でも対応できる。.htaccessを使うなら、下の２行を書けばOK。

Options +ExecCGI
AddHandler cgi-script pl

ここまで出来たら、awstatsを実行できる状態になっているはず。次のようにすると、awstatsはアクセスログを読みに行って、解析データを作成する。

/home/httpd/html/awstats/awstats.pl config=awstats.conf -update

次のように出力されたら成功。

/home/httpd/html/blog/awstats/awstats.pl config=awstats.conf -update
Update for config "/home/httpd/html/blog/awstats/awstats.conf"
With data in log file "/var/log/httpd/blog/access_log"...
Phase 1 : First bypass old records, searching new record...
Searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Jumped lines in file: 0
Parsed lines in file: 10
 Found 0 dropped records,
 Found 0 corrupted records,
 Found 0 old records,
 Found 10 new qualified records.

"Found n new qualified records."のところにゼロでない数字が入っていればOK。ここがゼロになってて、"Found n corrupted records,"のところに数字が入ってるなら、アクセスログの形式がだめぽである可能性が高い。apacheなら"combined"をログの形式にしていないとうまく扱ってくれかったとおもう、たぶん。アクセスログが見付からないとか、何か問題があるなら、その旨を教えてくれるはず。

最後にcronに仕込んで、定期的にawstatsを実行するようにしてやれば完璧。

で、このサーバで動いているawstatsはこちら。

http://blog.windy.ac/awstats/awstats.pl

前のエントリの続き。

MovableTypeのデータの格納にはPostgreSQLを使っている。pgAdmin(GUIなPostgreSQL管理ツール)でデータベースの中身を覗いてみると、確かにmt_fileinfoなんていうテーブルは作成されていない。とりあえずmt_fileinfoを作ってみるという方針にする。拡張子がpmだのcgiだのになってるファイルに片端からgrepを掛けると、アップグレード版のアーカイブに入っているmt-upgrade31.cgiの中に、mt_fileinfoを作成するコードが見つかった。

mt-upgrade31.cgiでは、設定されているデータベースの種類($mt->{cfg}->ObjectDriver)によって処理を切り分けて、データベースに対してテーブルの追加やインデックスの作成をし、スキーマを新しいバージョンのものに対応させる処理をしている。PostgreSQLに対する処理は110行目から153行目までにある。

elsif ($mt->{cfg}->ObjectDriver =~ /postgres/) {
        print "hoge";
        @stmts = add_once(\@stmts, $dbh, 'mt_blog', 'blog_ping_technorati', 'smallint')
            unless has_column($dbh, 'mt_blog', 'blog_ping_technorati');
        @stmts = add_once(\@stmts, $dbh, 'mt_blog', 'blog_children_modified_on', 'timestamp')
            unless has_column($dbh, 'mt_blog', 'blog_children_modified_on');
        push @stmts, ('alter table mt_blog add blog_custom_dynamic_templates varchar(25)',
                      "update mt_blog set blog_custom_dynamic_templates = 'none'")
            unless has_column($dbh, 'mt_blog', 'blog_custom_dynamic_template');
        @stmts = add_once(\@stmts, $dbh, 'mt_template', 'template_created_on', 'timestamp');
        @stmts = add_once(\@stmts, $dbh, 'mt_template', 'template_modified_on', 'timestamp');
        @stmts = add_once(\@stmts, $dbh, 'mt_template', 'template_created_by', 'integer');
        @stmts = add_once(\@stmts, $dbh, 'mt_template', 'template_modified_by', 'integer');
        push @stmts, ('alter table mt_template add template_build_dynamic smallint')
            unless has_column($dbh, 'mt_template', 'template_build_dynamic');
        push @stmts, ('update mt_template set template_build_dynamic = 0 where template_build_dynamic <> 1 or template_build_dynamic is null',
                      'alter table mt_template alter column template_build_dynamic set not null');
        push @stmts, ('alter table mt_category add category_parent integer',
                      'update mt_category set category_parent = 0',
                      'alter table mt_category alter column category_parent set not null')
            unless has_column($dbh, 'mt_category', 'category_parent');
        push @stmts, ("update mt_entry set entry_basename = '' where entry_basename is null",
                      'alter table mt_entry alter column entry_basename set not null');
        unless (has_column($dbh, 'mt_fileinfo', 'fileinfo_id')) {
            push @stmts, ＜＜FILEINFO;
create table mt_fileinfo (
    fileinfo_id integer primary key,
    fileinfo_blog_id integer not null,
    fileinfo_entry_id integer,
    fileinfo_url varchar(255),
    fileinfo_file_path text,
    fileinfo_template_id integer,
    fileinfo_templatemap_id integer,
    fileinfo_archive_type varchar(255),
    fileinfo_category_id integer,
    fileinfo_startdate varchar(80),
    fileinfo_virtual smallint
)
FILEINFO
            push @stmts, ("create sequence mt_fileinfo_id",
                          "create index mt_fileinfo_blog_id on mt_fileinfo (fileinfo_blog_id)",
                          "create index mt_fileinfo_entry_id on mt_fileinfo (fileinfo_entry_id)",
                          "create index mt_fileinfo_url on mt_fileinfo (fileinfo_url)");
        }
    }

ここで、@stmtsにpushされている文字列が、PostgreSQLに対して実行されるSQL文となっている。これを手作業で打ち込んで、mt_fileinfoテーブルを作ったり何だりしてやると、とりあえず動くようになった。いい加減な処置なので、まだどこかにエラーの種が残っているかもしれないけど。

PostgreSQLにはコマンドベースの管理ツール"psql"が付属している。これを下のように起動してやる。-Uでユーザ名、-dでデータベース名を指定する。

#psql -U postgres -d mt

で、あとはひたすらSQL文をこぴぺこぴぺ。

真夜中の４時くらいに突然、自宅サーバのMovableTypeをアップグレードしようと思い立った。何だか寝ようとしても寝付けない感じだったし。自宅サーバでは未だにVersion 2.65を使っていたのだが、これを日本語版の最新バージョンにしようとした。

MovableTypeの日本語版公式サイトからアップグレード版をダウンロード。解凍して出てきたファイルを古いバージョンのMTのディレクトリにまるごと上書きコピーして、mt-upgrade30.cgi → mt-upgrade31.cgiと実行してやれば良いらしい。楽勝ですね。さっそく言われたとおりにしてみると。

[shin@shalm MT]$ ./mt-upgrade30.cgi
Content-Type: text/html

<pre>

Upgrading your databases:

Running 'update mt_author set author_type = 1 where author_type <> 2 or author_type is NULL'

Running 'alter table mt_author add author_remote_auth_username varchar(50)'

Running 'alter table mt_author add author_remote_auth_token varchar(50)'

Running 'alter table mt_blog add blog_allow_unreg_comments smallint'

Running 'update mt_blog set blog_allow_unreg_comments = 1'

Running 'alter table mt_blog add blog_allow_reg_comments smallint'

Running 'update mt_blog set blog_allow_reg_comments = 1'

Running 'alter table mt_blog add blog_manual_approve_commenters smallint'

Running 'update mt_blog set blog_manual_approve_commenters = 0'

Running 'alter table mt_blog add blog_old_style_archive_links smallint'

Running 'update mt_blog set blog_old_style_archive_links = 1'

Running 'alter table mt_comment add comment_commenter_id integer'

Running 'alter table mt_comment add comment_visible smallint'

Running 'update mt_comment set comment_visible = 1'

Running 'alter table mt_blog add blog_require_comment_emails smallint'

Running 'alter table mt_blog add blog_moderate_unreg_comments smallint'

Running 'alter table mt_blog add blog_remote_auth_token varchar(50)'

Running 'alter table mt_entry add entry_basename varchar(50)'

Running 'create index mt_entry_basename on mt_entry (entry_basename)'

Running 'create table mt_session (

    session_id varchar(80) not null primary key,

    session_data text,

    session_email varchar(255),

    session_name varchar(255),

    session_start integer not null,

    session_kind varchar(2)

)

'

**** WARNING: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "mt_session_pkey" for table "mt_session"

Running 'create index mt_session_start on mt_session (session_start)'

Creating comment_pending template.

Done upgrading your schema! All went well.

</pre>

3.0へのアップグレードは何の問題もなく成功。なのだが、

[shin@shalm MT]$ ./mt-upgrade31.cgi
Content-Type: text/html

<pre>

Upgrading your databases:

Running 'alter table mt_blog add blog_ping_technorati smallint'

Running 'alter table mt_blog add blog_children_modified_on timestamp'

Running 'alter table mt_blog add blog_custom_dynamic_templates varchar(25)'

Running 'update mt_blog set blog_custom_dynamic_templates = 'none''

Running 'alter table mt_template add template_created_on timestamp'

Running 'alter table mt_template add template_modified_on timestamp'

Running 'alter table mt_template add template_created_by integer'

Running 'alter table mt_template add template_modified_by integer'

Running 'alter table mt_template add template_build_dynamic smallint'

Running 'update mt_template set template_build_dynamic = 0 where template_build_dynamic <> 1 or template_build_dynamic is null'

Running 'alter table mt_template alter column template_build_dynamic set not null'

Running 'alter table mt_category add category_parent integer'

Running 'update mt_category set category_parent = 0'

Running 'alter table mt_category alter column category_parent set not null'

Running 'update mt_entry set entry_basename = '' where entry_basename is null'

An error occurred while upgrading the schema:

ERROR:  column "entry_basename" does not exist on update mt_entry set entry_basename = '' where entry_basename is null at ./mt-upgrade31.cgi line 286.



</pre>

3.1へのアップグレードで失敗する。もう一回スクリプトを実行させると、

[shin@shalm MT]$ ./mt-upgrade31.cgi
Content-Type: text/html

<pre>

Upgrading your databases:

Running 'alter table mt_blog add blog_custom_dynamic_templates varchar(25)'

An error occurred while upgrading the schema:

ERROR:  column "blog_custom_dynamic_templates" of relation "mt_blog" already exists on alter table mt_blog add blog_custom_dynamic_templates varchar(25) at ./mt-upgrade31.cgi line 286.



</pre>

メッセージが変わるもののやはり失敗する。３回目以降は２回目と同じメッセージである。エラーメッセージを適当に切り出してgoogleに入れてみても解決に繋がる情報を取れない。3.0へのアップグレードには成功しているっぽいので、とりあえず3.0として使えればいいやと思う。3.0と3.1の違いもよく分かってないし。

……で、新しくなったMovableTypeにログインして、格好良くなってるインターフェースに感心したりしつつ弄くっていると、記事の追加でエラーが出ることに気付いた。

エラーが発生しました:

Couldn't create FileInfo because Insertion test failed on SQL error ERROR: relation "mt_fileinfo" does not exist

記事をDraftとして追加する分には問題なく、それをビルドしようとするときにエラーになるようだ。調べてみるとmt_fileinfoはHTMLを出力するときに使われるテーブルらしく、これがどうにかなってるらしい。あたま痛い。

さあ、どうしたものか。たぶん続く。

なんかnamedがだめぽ。外のIPアドレスを引くのは問題ないのだが、windy.acのゾーンへの問い合わせを捌けていない。dig @localhost windy.acとかやっても失敗してくれる。ログを見ると

[root@shalm ]# tail /var/log/messages
May 29 19:17:58 shalm named[5062]: listening on IPv4 interface lo, 127.0.0.1#53
May 29 19:17:58 shalm named[5062]: listening on IPv4 interface eth0, 192.168.1.1#53
May 29 19:17:58 shalm named[5062]: couldn't add command channel 127.0.0.1#953: not found
May 29 19:17:58 shalm named[5062]: couldn't add command channel ::1#953: not found
May 29 19:17:58 shalm named[5062]: running

とある。"couldn't add command channel"ってのが怪しいのでぐぐる。と、rndcとかいうリモートでnamedをコントロールするためのデーモンがちゃんと動いていないらしい。/etc/rndc.confやら/etc/rndc.keyやらをいじくるが一向に改善せず。わけわかめ。直截叩いてもなんか怒られるし。

[root@shalm ]# /usr/sbin/rndc status
rndc: connect failed: connection refused

つーかこのrndc、リモート操作のためだけのデーモンでnamedの動作にはまったく関わらないらしい。なのでrndcが動いていようがいまいがwindy.acのゾーンが引けないという問題には関係しないっぽい。さらにぐぐるとbindの設定ファイルをチェックするコマンドがあることが分かる。試してみる。

[root@shalm named]# /usr/sbin/named-checkconf /etc/named.conf
[root@shalm named]# /usr/sbin/named-checkzone windy.ac. /var/named/windy.ac.zone
/var/named/windy.ac.zone:2: no TTL specified; using SOA MINTTL instead
zone windy.ac/IN: loaded serial 2004053003
OK

設定ファイルは大丈夫っぽい。んじゃ何が悪いのだ。で、検索クエリに"fedora"を含めてみたらやっと原因に突き当たった。

http://www.linux.co.jp/bbs/bbs2/bbs.cgi?num=4671&ope=v&page=

Fedoraのbindはchrootされているようです
bind-chrootパッケージがインストールされて
設定ファイルは、下記ディレクトリに置くようです
/var/named/chroot/etc
/var/named/chroot/var/named

空のnamed.confファイルが/var/named/chroot/etcに作られています

つーわけで/etc/named.conf, /etc/rndc.conf, /etc/rndc.key, /var/named以下を/var/named/chroot以下のしかるべき場所に移動してnamedを再起動。ちゃんと動くようになりましたとさ。

……しかし、これにはfedoraの不親切さに文句を付けたいという気がする。デフォルトの状態で/var/named/chroot/etcに空っぽのnamed.confが作られており、こいつのせいで/etc/rc.d/init.d/named startを打てばとりあえずはnamedが起動してしまう。このために、設定ファイルを置く場所が間違っているということに気づきにくい。「BINDの設定ファイルは/etc/named.confに置く」ということが慣習としてあり、そこから逸れたことをしようとしているのだから、然るべきインストラクションを出すことが必要なんじゃないかしらん。エラーメッセージとして、"設定ファイルを/etc/named/chroot/以下においてください"って言ってくれればすぐに分かるのだから。

Fedoraでsshデーモンを立ち上げて、WindowsPCからTeratermProでログインしてみると日本語が化ける。

　バケラッタ

これが困ったことに設定をEUCにしてもS-JISにしても直らない。調べると、FedoraではコンソールがUnicode化されているらしい。先進的ですな。そりゃ化けるわけだ。

TeratermProではUnicodeを表示できないらしいので、他のsshクライアントを調べる。すると、Unicodeを表示することが出来、評価も高いsshクライアントとして、PuTTYというものがあるらしいことが分かった。

PuTTY
　http://www.chiark.greenend.org.uk/~sgtatham/putty/

Hideki EIRAKU氏が日本語化パッチを当てたものを公開されているので、オフィシャルから落として自分でパッチを当てるよりも、これを直截ダウンロードしに行ったほうが早い。

氏のページ
　http://hp.vector.co.jp/authors/VA024651/

パッチ適用済みPuTTY
　http://hp.vector.co.jp/authors/VA024651/download/file/puttykjbin.zip

これをダウンロードして、出てくるputtyjp.exeがPuTTYの本体。インストールは必要ない。文字コードにUnicodeを指定する方法だが、起動時に表示される"PuTTY 設定"というダイアログの、[カテゴリ]-[ウィンドウ]-[変換]の中の"受信されるデータの文字コード変換"という項目を設定する。コンボボックスの中から"UTF-8 (CJK)"を選択。ここでうっかり"UTF-8"を選んでしまうと化けてしまうので注意。(CJK)と付いているほうを選ぶこと。

これでFedoraのコンソールを文字化けなしで使えるようになった。

前回の続き。

私的なメモ用のblogのために運用していた「MovableType」を移行した。MovableTypeのverは2.64で、これをPostgreSQLと噛ませて動かしていた。PostgreSQLのverは7.2。

MovableType本体の移行は容易で、ディレクトリ構造を壊さないように移動してきてやればそれでOK。問題はPostgreSQLのデータをどうやったら移行できるかだが、調べてみるとpg_dumpallというコマンドが用意されており、これを使えばデータベースに格納されているすべてのデータをスクリプトとして書き出すことができるらしい。……だが、すでに我が自宅サーバは新しくインストールしたFedoraが立ち上がる状態になっている。pg_dumpallを走らせるにはPostgreSQL本体が動いている必要があり、そのためには古いVineLinuxなシステムを立ち上げるためにハードディスクを組み替えたりなんだりしなくてはならない。じつに面倒くさい。PostgreSQLのデータは/var/lib/pgsql/data以下に置かれるので、単純にこれを置き換えてなんとかならないかと思ってやってみるが、どうもうまくいかない。当たり前か。大人しくハードディスクを組み替えたりなんだりして古いシステムを立ち上げ、/etc/rc.d/init.d/postgresql statusでPostgreSQLが起動していることを確かめてから、

$/usr/bin/pg_dumpall > postgres.data

でスクリプトをファイルに書き出す。で、ハードディスクとかの構成を元に戻してFedoraを立ち上げて、同様に/etc/rc.d/init.d/postgresql statusでPostgreSQLが起動していることを確かめてから、

$su postgres
$createdb blog

でデータベースを作成(上のコマンドのなかで、"blog"のところは環境に依る。移行前のデータベースの名前を設定する)。作成したデータベースにpg_dumpallで書き出したスクリプトを適用。

$pgql blog < postgres.data

これでPostgreSQLのデータの移行が完了。

続いてapacheの設定ファイル(/etc/httpd/conf/httpd.conf)をいじる。Fedora Core 2はデフォルトの設定ではcgiが使えないようになっている。これを修正してcgiを使えるようにしてやるには、httpd.confの次の２行のコメントをはずす。

#AddHandler cgi-script .cgi
#AddHandler send-as-is　asis

httpd.confには、ついでに手を入れておくべき項目がある。デフォルトの状態だと、日本語がことごとく化けてしまうので、これを直しておいた方が良い。先ず、"AddDefaultCharset"に"off"を設定する（コメントアウトしても構わない）。また、"LanguagePriority"では"ja"を一番まえに持ってくる。これで文字化け対策もOK。

もう一つだけやるべきことがある。日本語版のMovableTypeを使っているなら、mt.cgiを実行するとJcode.pmが無い旨のエラーが出る。そこでMCPANを使って、

$perl -MCPAN -e "install 'Jcode'"

でJcode.pmをインストールする。MCPANの起動が初めてだと、設定事項をいろいろと尋ねられる。いちいち答えるのが面倒ならすべてリターンを押してかまわない。

これでMovableTypeの移行が完了。めでたしめでたし。

自宅サーバのOSはVineLinuxの2.15だか2.6だかなのだが、ヘンにいじくりまわしたせいであっちこっちがおかしくなっていた。どこがおかしいのかというとそれはもう挙げていたら切りがないというくらいなのだが、その中でもいちばん困るのがrpmがぶっ壊れてしまっているということ。

[shin@shalm shin]$ rpm -qa
　cannot open file //var/lib/rpm/nameindex.rpm: 無効な引数です
　rpmQuery: rpmdbOpen() failed

調べても直し方がわからず、せっかくredhat系のLinuxを使っているのにrpmの恩恵を受けられない状態になっていた。ソフトウェアをインストールするのに、いちいちソースコードからコンパイルするのは面倒くさい。どうにかしたいと思っていたところにタイミング良くFedora Core 2がリリースされたので、これ幸いとインストールしてみた。

vineに対してアップデート・インストールをするのは不安なので、新しくパーティションを切って新規にインストールした。パッケージの総容量は6GB超で、掛かった時間はおよそ３時間。どんどんでかくなっていきますね。

　かっちょいいログイン画面

インストールの完了後、vineの入ったパーティションをマウントして、サーバ環境の移行作業をする。先ず/etc/passwd、/etc/group、/etc/shadowの３つを、古いのと新しいのを付き合わせてマージする。ついでに/etc/fstabをいじって別パーティションに切ってあった/homeをマウントしてやる。これでユーザ情報を復元。

続いてapache、postfix、bindの設定を復旧。apacheはvineではver1.xだったものがFedoraでは2.xになっているため、これも古いのと新しいのを並べてemacsで開いてマージする。/etc/rc.d/init.d/httpd startで立ち上げて、ブラウザで適当にページを開いてみて、動いていることを確認。postfix。古い設定ファイルを持ってきてもエラーを吐くので、同様にマージ。bindは古い設定ファイルそのままでOK。楽ちん。

続いてpopデーモンだが、ここではまった。Fedoraのデフォルトなpopデーモンがdovecotなる代物であることを知り、これを使おうと試みるも、どうしても動いてくれない。調べて真っ先に出てくるのが/etc/dovecot.confに

protocols = imap imaps pop3 pop3s

を書き足せっていうことだが、これではだめぽ。どうも認証時にリジェクトされてしまう。DOS窓からtelnetで叩いてみると、

C:\Documents and Settings\shin>telnet windy.ac 110
+OK dovecot ready.
USER shin
+OK
PASS xxxxxxxxxxxxxxxxx
+OK Logged in.
* BYE Internal login failure.

ホストとの接続が切断されました。

んー。なんですか、それ。/var/log/maillogを見ると、

May 21 15:15:33 shalm dovecot: Invalid chroot directory: /home/shin
May 21 15:15:33 shalm pop3-login: Internal login failure: shin [192.168.1.3]

とある。メールのspoolは/var/spool/mail/shinなので、ここで/home/shinをどうにかしに行くのは明らかに間違った動作だと思われる。/etc/dovecot.confのそれっぽい項目をいじっても改善しない。というか、このdovecot、いまいちマイナーなデーモンらしく、googleで調べてもまったく情報が引っかかってこない。すこし設定ファイルをいじってみて、ギブアップ。他のpopデーモンを使う方向に転回。

で、vineで使っていたqpopperを使うことにした。最初は気付かなかったのだがFedoraにはqpopperもデフォルトでインストールされていて、/etc/xinetd.d/pop3で設定されている。これに

desable=no

の１行を書き足して、/etc/rc.d/init.d/xinetd restartでxinetdを再起動。これでふつーにメールを受信できるようになった。

……というわけで現状はここまで。まだsambaやらpostgresqlやらと移行ができていないモノがあるので、もう少しいじらないと。

追記：
それにしてもFedora、リリースから数日経った現在、あまり評判がよろしくない。2chのスレでもトラブルの報告が多いし、Fedoraのwikiでの「インストールした人はどうでしたか?」というアンケートの結果はいま現在で

うまくインストールできてそこそこ使ってる 60
インストールできたけどうまく動かない 58
そもそもインストールが出来ない 32

という結果になっている。そこそこ使えているひとの割合がちょっと低いのではないかしら。人柱OSの予感がする。