さくらインターネット創業日記

先日、「さくらのVPS」のベータテストが開始されました。
私も個人的にさくらのレンタルサーバを利用しているので、7月14日にフライングして申し込みしました。
（最終テスト中だったようで、社員にまじめに怒られてしまいましたが・・。スイマセン）

まず基本仕様

• CPU 2コア


• メモリー 512MB


• HDD 20GB


• ネットワーク 100Mbps(いちおうの上限)


• リモートコンソール付き


• 再起動、再インストールは、セルフサービスでコンパネから可能

ホスト側は、QuadCore Xeonで、1Gbpsにて上位スイッチに接続し、10Gbpsでさくらインターネットの基幹ネットワークに接続しています。
（クローズドベータテスト中に400Mbps位出たという記事もありましたが、さすがに対策する予定です）

ハイパーバイザーは、巷の格安VPSで多く利用される、VirtuaozzoやOpenVZ、Xenの準仮想化と異なり、KVMで完全仮想化になっています。
完全に512MBの実メモリを割当しますから、ホストOS側でスワップされずパフォーマンスが低下しないですし、ゲスト環境側でスワップを用意することも可能です。

実メモリは、ゲストで必要とするメモリ容量の1.5倍?2倍程度を搭載しています。
というのは、ホストOSのメモリの2/3以上をゲストに割り当てると、過負荷時のレスポンスが急激に悪化したり、不安定になったりということが言われており、当社でも再現されているので、余裕を持った設計にしています。
さらに、ホストOSのメモリの余裕を持たすことで、ディスクI/Oも劇的によくなります。
ゲストOSのスワップ時でも、ホストOSのキャッシュに入っていれば、メモリの延長上といえるかもしれません。

このように、100Mbpsインターフェース、20GBのHDD、2 CPU、512MBメモリといっても、同種のVPSサービスとは一線を画します。
その上で、「格安VPS」といえる価格帯で出す予定にしていますので、海外にも増してメリットのあるサービスになるのではと考えています。

と、宣伝はここまでにして、早速利用してみます。

まず、私が行ったのは、sshの公開鍵を設置してrootログインできないようにすることです。
申し込み直後は、ほぼ最新のパッチを当てて出荷されますので、いきなりクラックされることは考えなくてもよいと思いますが、なんとなく不安です。
（対策として、ネットワークをシャットダウンしたまま出荷するオプションを用意するなど、検討の余地があると考えています。）

ということで、ssh-keygenを行い、/etc/ssh/sshd_configにrootでのパスワードログインを禁止します。

[root@www10xxu ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
1b:f0: root@www10xxu.sakura.ne.jp
[root@www10xxu ~]#

/etc/ssh/sshd_config
変更前
PermitRootLogin yes
変更後
PermitRootLogin without-password

[root@www10xxu ~]# service sshd restart

次に無駄なデーモンをoffにします。
さくらのVPSの初期状態において脊髄反射で感じるのは「思いのほか空きメモリが少ない！」ということです。

ps -aux結果

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  10348   688 ?        Ss   Jul15   0:00 init [3]
root         2  0.0  0.0      0     0 ?        S<   Jul15   0:03 [migration/0]
root         3  0.0  0.0      0     0 ?        SN   Jul15   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S<   Jul15   0:00 [watchdog/0]
root         5  0.0  0.0      0     0 ?        S<   Jul15   0:01 [migration/1]
root         6  0.0  0.0      0     0 ?        SN   Jul15   0:00 [ksoftirqd/1]
root         7  0.0  0.0      0     0 ?        S<   Jul15   0:00 [watchdog/1]
root         8  0.0  0.0      0     0 ?        S<   Jul15   0:00 [events/0]
root         9  0.0  0.0      0     0 ?        S<   Jul15   0:00 [events/1]
root        10  0.0  0.0      0     0 ?        S<   Jul15   0:00 [khelper]
root        15  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kthread]
root        20  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kblockd/0]
root        21  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kblockd/1]
root        22  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kacpid]
root        90  0.0  0.0      0     0 ?        S<   Jul15   0:00 [cqueue/0]
root        91  0.0  0.0      0     0 ?        S<   Jul15   0:00 [cqueue/1]
root        94  0.0  0.0      0     0 ?        S<   Jul15   0:00 [khubd]
root        96  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kseriod]
root       168  0.0  0.0      0     0 ?        S    Jul15   0:00 [khungtaskd]
root       169  0.0  0.0      0     0 ?        S    Jul15   0:00 [pdflush]
root       170  0.0  0.0      0     0 ?        S    Jul15   0:00 [pdflush]
root       171  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kswapd0]
root       172  0.0  0.0      0     0 ?        S<   Jul15   0:00 [aio/0]
root       173  0.0  0.0      0     0 ?        S<   Jul15   0:00 [aio/1]
root       317  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kpsmoused]
root       361  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata/0]
root       362  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata/1]
root       363  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata_aux]
root       373  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kstriped]
root       386  0.0  0.0      0     0 ?        S<   Jul15   0:04 [kjournald]
root       407  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kauditd]
root       435  0.0  0.1  12672   764 ?        S<s  Jul15   0:00 /sbin/udevd -d
root      1059  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kmpathd/0]
root      1060  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kmpathd/1]
root      1062  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kmpath_handlerd]
root      1112  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kjournald]
root      1429  0.0  0.1   5908   608 ?        Ss   Jul15   0:00 syslogd -m 0
root      1432  0.0  0.0   3804   424 ?        Ss   Jul15   0:00 klogd -x
dbus      1492  0.0  0.1  21256   964 ?        Ss   Jul15   0:00 dbus-daemon --system
root      1501  0.0  0.1   3800   580 ?        Ss   Jul15   0:00 /usr/sbin/acpid
68        1509  0.0  0.7  30604  3660 ?        Ss   Jul15   0:00 hald
root      1510  0.0  0.2  21692  1056 ?        S    Jul15   0:00 hald-runner
68        1518  0.0  0.1  12324   844 ?        S    Jul15   0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
68        1523  0.0  0.1  12324   848 ?        S    Jul15   0:00 hald-addon-keyboard: listening on /dev/input/event0
root      1532  0.1  0.1  10228   680 ?        S    Jul15   4:09 hald-addon-storage: polling /dev/hdc
root      1547  0.0  0.2  62624  1208 ?        Ss   Jul15   0:00 /usr/sbin/sshd
ntp       1558  0.0  0.9  23388  5028 ?        SLs  Jul15   0:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
root      1576  0.0  0.4  69004  2348 ?        Ss   Jul15   0:00 sendmail: accepting connections
smmsp     1584  0.0  0.3  59764  1800 ?        Ss   Jul15   0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root      1593  0.0  0.2  19708  1144 ?        Ss   Jul15   0:00 crond
root      1601  0.0  0.0  18732   456 ?        Ss   Jul15   0:00 /usr/sbin/atd
root      1615  0.0  0.2  52108  1332 ?        Ss   Jul15   0:00 login -- root
root      1616  0.0  0.0   3792   480 tty2     Ss+  Jul15   0:00 /sbin/mingetty tty2
root      1617  0.0  0.0   3792   484 tty3     Ss+  Jul15   0:00 /sbin/mingetty tty3
root      1628  0.0  0.0   3792   480 tty4     Ss+  Jul15   0:00 /sbin/mingetty tty4
root      1629  0.0  0.0   3792   480 tty5     Ss+  Jul15   0:00 /sbin/mingetty tty5
root      1640  0.0  0.0   3792   480 tty6     Ss+  Jul15   0:00 /sbin/mingetty tty6
root      1641  0.0  0.1   3800   536 ttyS0    Ss+  Jul15   0:00 /sbin/agetty -h 115200 ttyS0 vt100
root      1684  0.0  3.1 201952 15920 ?        SN   Jul15   0:00 /usr/bin/python -tt /usr/sbin/yum-updatesd
root      1686  0.0  0.2  12916  1160 ?        SN   Jul15   0:00 /usr/libexec/gam_server
root      1722  0.0  0.6  90320  3528 ?        Ss   Jul15   0:00 sshd: root@pts/0
root      1724  0.0  0.2  10932  1440 pts/0    Ss+  Jul15   0:00 -bash
root      1758  0.0  0.2  10928  1372 tty1     Ss+  Jul15   0:00 -bash
root     10606  0.0  0.6  91048  3380 ?        Rs   13:17   0:00 sshd: root@pts/1
root     10608  0.0  0.2  10932  1392 pts/1    Ss   13:17   0:00 -bash
root     10643  0.0  0.1  10460   876 pts/1    R+   13:38   0:00 ps -aux

まず、コンソール（mingetty）はこんなに要らないので、減らします。

/etc/inittabを以下のように編集

# Run gettys in standard runlevels

1:2345:respawn:/sbin/mingetty tty1

#2:2345:respawn:/sbin/mingetty tty2

#3:2345:respawn:/sbin/mingetty tty3

#4:2345:respawn:/sbin/mingetty tty4

#5:2345:respawn:/sbin/mingetty tty5

#6:2345:respawn:/sbin/mingetty tty6

デーモンも減らします。

[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig haldaemon off
[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig acpid off
[root@www10xxu ~]# chkconfig messagebus off

これで再起動すれば、ずいぶんとメモリの空きができます。
再起動後に確認すると、使用中は150MBとなっていました。もう少しがんばれば、もっと削減できそうです。

なお、unixbenchも実行してみました。
index scoreは1540.6ですので、そこそこ速いのではないでしょうか。

   #    #  #    #  #  #    #          #####   ######  #    #   ####   #    #
   #    #  ##   #  #   #  #           #    #  #       ##   #  #    #  #    #
   #    #  # #  #  #    ##            #####   #####   # #  #  #       ######
   #    #  #  # #  #    ##            #    #  #       #  # #  #       #    #
   #    #  #   ##  #   #  #           #    #  #       #   ##  #    #  #    #
    ####   #    #  #  #    #          #####   ######  #    #   ####   #    #

   Version 5.1.2                      Based on the Byte Magazine Unix Benchmark

   Multi-CPU version                  Version 5 revisions by Ian Smith,

                                      Sunnyvale, CA, USA

   December 22, 2007                  johantheghost at yahoo period com



1 x Dhrystone 2 using register variables  1 2 3 4 5 6 7 8 9 10

1 x Double-Precision Whetstone  1 2 3 4 5 6 7 8 9 10

1 x Execl Throughput  1 2 3

1 x File Copy 1024 bufsize 2000 maxblocks  1 2 3

1 x File Copy 256 bufsize 500 maxblocks  1 2 3

1 x File Copy 4096 bufsize 8000 maxblocks  1 2 3

1 x Pipe Throughput  1 2 3 4 5 6 7 8 9 10

1 x Pipe-based Context Switching  1 2 3 4 5 6 7 8 9 10

1 x Process Creation  1 2 3

1 x System Call Overhead  1 2 3 4 5 6 7 8 9 10

1 x Shell Scripts (1 concurrent)  1 2 3

1 x Shell Scripts (8 concurrent)  1 2 3

2 x Dhrystone 2 using register variables  1 2 3 4 5 6 7 8 9 10

2 x Double-Precision Whetstone  1 2 3 4 5 6 7 8 9 10

2 x Execl Throughput  1 2 3

2 x File Copy 1024 bufsize 2000 maxblocks  1 2 3

2 x File Copy 256 bufsize 500 maxblocks  1 2 3

2 x File Copy 4096 bufsize 8000 maxblocks  1 2 3

2 x Pipe Throughput  1 2 3 4 5 6 7 8 9 10

2 x Pipe-based Context Switching  1 2 3 4 5 6 7 8 9 10

2 x Process Creation  1 2 3

2 x System Call Overhead  1 2 3 4 5 6 7 8 9 10

2 x Shell Scripts (1 concurrent)  1 2 3

2 x Shell Scripts (8 concurrent)  1 2 3

========================================================================

   BYTE UNIX Benchmarks (Version 5.1.2)

   System: www1010u.sakura.ne.jp: GNU/Linux

   OS: GNU/Linux -- 2.6.18-194.8.1.el5 -- #1 SMP Thu Jul 1 19:04:48 EDT 2010

   Machine: x86_64 (x86_64)

   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")

   CPU 0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5319.4 bogomips)

          x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET

   CPU 1: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5290.9 bogomips)

          x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET

   10:15:43 up 1 day, 19:18,  2 users,  load average: 0.02, 0.02, 0.00; runlevel 3

------------------------------------------------------------------------

Benchmark Run: Sat Jul 17 2010 10:15:43 - 10:43:56

2 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       14188657.9 lps   (10.0 s, 7 samples)

Double-Precision Whetstone                     3011.2 MWIPS (9.8 s, 7 samples)

Execl Throughput                               1775.5 lps   (29.6 s, 2 samples)

File Copy 1024 bufsize 2000 maxblocks        709457.6 KBps  (30.0 s, 2 samples)

File Copy 256 bufsize 500 maxblocks          210832.6 KBps  (30.0 s, 2 samples)

File Copy 4096 bufsize 8000 maxblocks       1449865.3 KBps  (30.0 s, 2 samples)

Pipe Throughput                             1955338.6 lps   (10.0 s, 7 samples)

Pipe-based Context Switching                 259909.8 lps   (10.0 s, 7 samples)

Process Creation                               8795.8 lps   (30.0 s, 2 samples)

Shell Scripts (1 concurrent)                   4125.4 lpm   (60.0 s, 2 samples)

Shell Scripts (8 concurrent)                   1416.6 lpm   (60.0 s, 2 samples)

System Call Overhead                        3385128.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX

Dhrystone 2 using register variables         116700.0   14188657.9   1215.8

Double-Precision Whetstone                       55.0       3011.2    547.5

Execl Throughput                                 43.0       1775.5    412.9

File Copy 1024 bufsize 2000 maxblocks          3960.0     709457.6   1791.6

File Copy 256 bufsize 500 maxblocks            1655.0     210832.6   1273.9

File Copy 4096 bufsize 8000 maxblocks          5800.0    1449865.3   2499.8

Pipe Throughput                               12440.0    1955338.6   1571.8

Pipe-based Context Switching                   4000.0     259909.8    649.8

Process Creation                                126.0       8795.8    698.1

Shell Scripts (1 concurrent)                     42.4       4125.4    973.0

Shell Scripts (8 concurrent)                      6.0       1416.6   2361.0

System Call Overhead                          15000.0    3385128.4   2256.8

                                                                   ========

System Benchmarks Index Score                                        1157.7

------------------------------------------------------------------------

Benchmark Run: Sat Jul 17 2010 10:43:56 - 11:12:10

2 CPUs in system; running 2 parallel copies of tests

Dhrystone 2 using register variables       27985122.2 lps   (10.0 s, 7 samples)

Double-Precision Whetstone                     5992.4 MWIPS (9.7 s, 7 samples)

Execl Throughput                               7332.5 lps   (30.0 s, 2 samples)

File Copy 1024 bufsize 2000 maxblocks        218518.6 KBps  (30.0 s, 2 samples)

File Copy 256 bufsize 500 maxblocks           63801.8 KBps  (30.0 s, 2 samples)

File Copy 4096 bufsize 8000 maxblocks        502186.1 KBps  (30.0 s, 2 samples)

Pipe Throughput                             3771938.1 lps   (10.0 s, 7 samples)

Pipe-based Context Switching                 775819.3 lps   (10.0 s, 7 samples)

Process Creation                              20049.5 lps   (30.0 s, 2 samples)

Shell Scripts (1 concurrent)                   9979.2 lpm   (60.0 s, 2 samples)

Shell Scripts (8 concurrent)                   1579.2 lpm   (60.0 s, 2 samples)

System Call Overhead                        5635202.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX

Dhrystone 2 using register variables         116700.0   27985122.2   2398.0

Double-Precision Whetstone                       55.0       5992.4   1089.5

Execl Throughput                                 43.0       7332.5   1705.2

File Copy 1024 bufsize 2000 maxblocks          3960.0     218518.6    551.8

File Copy 256 bufsize 500 maxblocks            1655.0      63801.8    385.5

File Copy 4096 bufsize 8000 maxblocks          5800.0     502186.1    865.8

Pipe Throughput                               12440.0    3771938.1   3032.1

Pipe-based Context Switching                   4000.0     775819.3   1939.5

Process Creation                                126.0      20049.5   1591.2

Shell Scripts (1 concurrent)                     42.4       9979.2   2353.6

Shell Scripts (8 concurrent)                      6.0       1579.2   2632.1

System Call Overhead                          15000.0    5635202.3   3756.8

                                                                   ========

System Benchmarks Index Score                                        1540.6

と、雑多にまとめてみました。

なお、ただいまベータテスト中で、追加予定機能は山のようにあるので、状況を見ながらアップデートして行きたと思います。
ツイッターでもさまざまな要望を頂いていますが、ぜひ参考にさせていただきたいので、コンパネ上の「ご意見・ご要望」もご活用ください。

最近KVS（Key-Value-Storage）が流行っていますが、うちの研究所においても「えとらぼ」さんと共同でkumofsの研究をしています。
色々とバギーなところも多いのですが、最新パッチを頂きながら、それなりに成果が出てきたようです。
kumofsの詳細については、さくらインターネット研究所に任せることにして、今回は一般にソースが公開されたこともあるので個人的にインストールした際のログを紹介します。

1. まず関連する諸ライブラリのインストール

libtoolのインストール
# yum install libtool

OpenSSLのインストール
# yum install openssl-devel

BZip2ライブラリのインストール（tokyo cabinetインストールのために必要）
# yum install bzip2-devel

2. msgpackのインストール

ダウンロード
http://msgpack.sourceforge.jp/

私は、msgpack-0.4.0.tar.gzをダウンロードしました。

ここで注意！
私の環境で ./configure && make した際、インストールは無事完了したものの、いざライブラリを使おうと思うと、__sync_sub_and_fetch_4が無いとのエラーが出ました。

kumofsの./configureをconfig.logより

__sync_sub_and_fetchというのは、マルチスレッド環境下においてアトミックな加算処理を行うためのgcc組み込み関数ですが、なぜか_4が付いてしまっています。
これはgccの仕様で、引数の型を見て、その型のビット長を付けるためだと分かりました。
例えば今回の場合、4バイトなので 「_4」 をつけられています。
まあ、これはいいのですが、-march=i686をつければgccの挙動が変わるとのことなので、msgpackの./configure前には CFLAGSとCPPFLAGSにセットしておくことで回避しました。

# tar xvfz msgpack-0.4.0.tar.gz
# cd msgpack-0.4.0
# export set CFLAGS=-march=i686
# export set CPPFLAGS=-march=i686
# ./configure
# make
# make install

※参考になったサイト
仙石浩明の日記: __sync_bool_compare_and_swap_4 とは何か？ ? glibc をビルドする場合は、 gcc の --with-arch=i686 configure オプションを使ってはいけない

3. tokyo cabinet のインストール

http://1978th.net/tokyocabinet/
私は、バージョン1.4.41をダウンロードしました。

# tar xvfz tokyocabinet-1.4.41.tar.gz
# cd tokyocabinet-1.4.41/
# ./configure
# make
# make install

4. kumofsのインストール

ダウンロードは、古橋さんのサイトからできます。
http://d.hatena.ne.jp/viver/20100118/p1

私は、githubよりkumofs-0.3.0 をダウンロードしました。

次に /usr/local/lib がライブラリに含まれるよう、環境変数をセット。
（私の場合、新しい環境だったので、これがないと cannot find -lmsgpack となりました）

# export set LDFLAGS=-L/usr/local/lib

早速ビルドを開始

# ./bootstrap
# ./configure
# make
# make install

とりあえず、インストールは完了したようです。

早速起動と行きたいところですが、また時間を見つけてクラスターを組んでみたいと思います。

なお、うちの研究所では型落ちのサーバを山のように用意して、実験をしているようですので、パフォーマンスなど実際のレポートは、そちらを期待してください。
私のほうでは、とりあえず画像生成サイトなど、個人的にやっているいくつかのサイトのバックエンドを、kumofsにしてみようかと思っています。
Apache用のmod_kumofsとかを作って、kumofsに格納されたバリューを、直接クライアントに返すなんてこともやってみたいところです。

将来的には、mysqlのように、共用サーバやクラウドでのインスタンス貸しをしてみたいものですね。

いろんな人たちから「何やってんだ（笑）」と言われつつも、とある櫻花の画像生成が完成しました。


http://to-a.ru

元ネタは言わなくてもお分かりいただけるでしょうが、某禁書目録や某超電磁砲のタイトル風画像を作れるだけのサイトです。
ちなみに、「とある画像の自動生成」というサイトが既にあるのですが、Silverlightベースなのでクライアントのインストールが必要ですし、そのほかにも改良したいところが多かったので、自分で作りました。

改良したところ

• サーバでの生成方式に変えた
• グラデーションの粒度を細かくした
• すべての文字にアンチエイリアスをかけた
• フォントを極太明朝に変えた（HG明朝Ｅ）
• サーバへの保存機能を設けた
• とある???で、3文字入力を可能にした→ ex. とあるラジオの超電磁砲

今回は、ＰＨＰ＋ＧＤで書いたのですが、文字に斜めの滑らかなグラデーションをかけるのは意外と難しく、文字データとグラデーションを別個で作って、独自のルーチンで合成するということをしました。
ImageMagickのレイヤーを使えば簡単だと言う情報をさまざまな人から寄せられたのですが、「プログラマたるもの制約の中で最高のアウトプットを出さんとあかん」ということで、ＧＤのままです。（といいつつ、「ここまで作ったしＧＤでいいや」ってのが本音ですｗｗ）

まず、グラデーションを生成するコード。

ずいぶんとご無沙汰してましたが、あまり間が空くのもよろしくないので、少し仕事から離れたところで・・。

さて、1週間ほど前から、近所のソフマップ天王寺店の店頭にて、D945GCLF2というデュアルコアAtomを搭載したマザーが売られており、面白そうだったので買ってみました。
Atomには以前から興味があったものの、動作が少しもっさりしてるとのことで、1代前のD945GCLF（Atom230搭載）は敬遠してました。ただ、D945GCLF2では、デュアルコアのAtom330を搭載して、HTにも対応とのことで、HT有効時には4CPU分として利用できることもあり、悪くなさそうです。
また、SSDの32GBが１万円を切っており、せっかくなので両方試してみることにしました。

なお、マザーボード自体は、USBは当然のことながら、PCIバス1スロット、1000BaseT対応のLANポート、SATA×2ポート、PATA×1ポートなど、必要なものはすべて用意されています。また、PCIバスにLANカードを挿せば2ポートを実現できますし、RAIDカードも挿せますから、それなりに本格的なサーバとしても利用できそうです。

で、完成した写真は右のとおり。
５インチベイもあるケースでしたが、インストール時にDVDドライブをつけてみたものの、放熱が悪そうなこともあり、取り外してしまいました。
感想としては、発熱も音も少なく、なかなか良いハードウェアだと思います。

次にOSインストールですが、今回はCentOS5.2にしました。これがまた曲者で、今回はネットワークカードとSATAディスクのエラーの両方でかなりてこずりました。
まず、ネットワークカードですが、認識されるのに通信ができないという事態に見舞われます。原因は、実際に載っているチップがRTL8111なのに、r8169（RealtekのRTL8169）として認識されていることのようです。仕方がないので、とりあえず予備でおいてあったバッファローのLGY-PCI-GT（RTL8169搭載）を利用してeth1として認識させることに。
実際の運用開始時には、RealtekのウェブサイトからLinux版のドライバをダウンロードしインストールすることで解決します（後述）が、とりあえずインストールのときはeth1を利用しました。

そして、とりあえずネットワークカードはいったん問題を回避したものの、インストール後に、ディスク関係のエラーが山のように出るという問題に遭遇。そればかりか、延々とエラーが続き、マルチユーザモードでは立ち上がる気配すら見せません。
ためしに、SSDではなくハードディスクにインストールしてみると問題なかったのですが、せっかくSSDを買ったにもかかわらず使えないのも負けた気がするので、いろいろ調査した結果、カーネルのパラメータにirqpollを付加して急場しのぎができました。いや、これで数時間悩んでしまいました。

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x24
ata1.00: cmd 35/00:20:75:c9:03/00:02:00:00:00/e0 tag 0 dma 278528 out
         res 51/04:00:00:00:00/04:00:00:00:00/a0 Emask 0x1 (device error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { ABRT }
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 62881792 512-byte hdwr sectors (32195 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write through
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x24
ata1.00: cmd ca/00:18:9d:ce:03/00:00:00:00:00/e0 tag 0 dma 12288 out
         res 51/04:00:00:00:00/04:00:00:00:00/a0 Emask 0x1 (device error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { ABRT }
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 62881792 512-byte hdwr sectors (32195 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write through
[drm] Initialized drm 1.0.1 20051102
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 233
[drm] Initialized i915 1.8.0 20060929 on minor 0
hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request.

とりあえず、以下のように/boot/grub/grub.confを修正

title CentOS (2.6.18-92.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup01/LogVol00 rhgb quiet irqpoll ←ココ
	initrd /initrd-2.6.18-92.el5.img

なお、上で書いたとおり、ネットワークカードが認識されていないので、RTL8111用のドライバインストールが必要です。
ドライバは、Realtekのウェブサイトからダウンロードでき、私がダウンロードしたのは r8168-8.008.00.tar.bz2というものでした。
これを、どこかのディレクトリで展開し、readmeファイルにあるとおりにインストールすれば完了です。

# make clean modules
# make install
# depmod -a
# insmod ./src/r8168.ko
# lsmod | grep r8168
r8168                  36884  0 ← 表示されればOK

alias eth0 r8168 ← 通常にインストールすると r8169になってしまっているはず

# ethtool -i eth0
driver: r8168
version: 8.008.00-NAPI
firmware-version:
bus-info: 0000:01:00.0

これですべて終わりです。

なお、デュアルコアでかつHT対応なので、/proc/cpuinfoでは4つのCPUが見えています。シングルスレッドでシングルプロセスの場合には、それほどパフォーマンスに差は出ないかもしれませんが、サーバソフトウェアの多くは対応していると思われるので、十分に力を使いきれるのではないでしょうか。
Atom330のcpuinfo - 20080928-atom-cpuinfo.txt
ちなみに、BogoMIPSは12772.97と出ました。

Total of 4 processors activated (12772.97 BogoMIPS).

ディスクI/Oのほうは、SSDとHDDのパフォーマンスの差がなく、少々残念な結果になりました。

# hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  190 MB in  3.03 seconds =  62.72 MB/sec
# hdparm -t /dev/sdb
/dev/sdb:
 Timing buffered disk reads:  190 MB in  3.00 seconds =  63.32 MB/sec

 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 setting 32-bit IO_support flag to 1
 HDIO_SET_32BIT failed: Invalid argument

                     INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX
Arithmetic Test (type = double)              29820.0   159570.8       53.5
Dhrystone 2 using register variables        116700.0  2834237.1      242.9
Execl Throughput                                43.0     1245.6      289.7
File Copy 1024 bufsize 2000 maxblocks         3960.0   102713.0      259.4
File Copy 256 bufsize 500 maxblocks           1655.0    28882.0      174.5
File Copy 4096 bufsize 8000 maxblocks         5800.0   299036.0      515.6
Pipe Throughput                              12440.0   187493.0      150.7
Pipe-based Context Switching                  4000.0    45235.4      113.1
Process Creation                               126.0     5403.1      428.8
Shell Scripts (8 concurrent)                     6.0      538.7      897.8
System Call Overhead                         15000.0   324813.4      216.5
                                                                 =========
     FINAL SCORE                                                     235.7

とりあえず、ディスク周りではまだ完璧で無い感があるものの、実際に利用した感想としては、予想以上にパフォーマンスが高いと思います。X上でFirefoxを利用していますが、ストレスは全く感じません。
また、バックグラウンドで地デジ録画をしながらでも、別の作業が重くなるということもなく、今のところは全く不満ありません。

トータルで3万円程度で自宅サーバ、ぜひ皆さんもいかがでしょうか。

先日、「Web屋のネタ帳」というブログから、「さくらインターネットの会員メニュー画面のセッション情報はログアウトしても1年たっても消えない件」という旨のトラックバックがありました。
それによると、「クッキーを保存しておくと、１年後でもログインできる」といった内容で、クッキーを保存する人なんておるんかいなと思いつつも、実際に保存していた人が居たことに、少し興味が惹かれました。
ただ、指摘されている内容については、実際と異なることも多く、当該ブログの管理者様にはコメントだけお送りしたのですが、特に返事の無いまま、飛び火をして憶測だけが流れ続けていることに少し憂慮しており、ここで解説させて頂くことにしました。

ちなみに、「考え」の部分は、私個人の考えですので、その点はお含みおきください。

まず初めに、当該ブログにおいて指摘されている点を以下の２点に要約します。

• セッション管理をする際にはログアウト時にセッション破棄を行わなければならない


• ログインからしばらくたった後（１年後）もそのまま利用できるのは、良くない

１点目は技術的な指摘であり、会員メニューがセッション管理を行っていたならば、当然ログアウト時にセッション破棄を行わなければならないというのは、書いているとおりです。この部分のみを切り取ってみれば、間違いありません。
しかし、会員メニューに当てはめてみると、これには重大な間違いがあります。
それは何かというと、会員メニューではセッション管理をしていないということです。なので、セッションを破棄するという動作がそもそもありません。
つまり、問題点その１と、問題点その２は、会員メニューには当てはまりませんので、ご安心ください。

２点目はポリシー的な指摘であり、考えが分かれるところです。
ただ、管理者の方が指摘されている、「ログインしてから１年以上もたった後に解約できるのは問題」という部分は間違っており、実際にはログイン後に一定時間が過ぎると、パスワードの再確認がなされます。また、住所変更や、クレジットカードの表示・変更の場合にも、同様の処理が行われます。
すなわち、問題点その３についても、会員メニューには当てはまりません。
（後ほど、管理者によって修正されています。ありがとうございます）
もちろん、サーバ設定については一定期間経過後にできないようにすればとの意見もあると思いますが、逆に不便になる点もあり「考えが分かれる」と表記させて頂きました。

ところで、セッション管理というキーワードが出てきましたので、ユーザ認証が必要なサイトに関して、すこし解説をさせていただく事にします。
まず、ユーザ認証が必要なサイトに関して、以下に代表的な３種類をあげさせていただきました。

1. セッションで管理する

ユーザ名とパスワードはログインを行う場合のみデータベースへ確認し、その後はサーバとブラウザがセッションＩＤと呼ばれるランダムに生成された文字列を共有して、認証行います。
比較的多く利用されている手法で、今回ご指摘頂いた管理者の方の意見も、これをベースとされています。
たとえるならば、カード表面にランダムに振られた番号の書かれた印鑑登録カードと同じようなものです。最初に免許書等で本人確認を行い、それ以降はカード番号の記された印鑑登録カードを持っていくだけで印鑑登録証明書が発行されるのに似てるでしょう。
2. その都度ユーザ名とパスワードを送る

その都度、ユーザ名とパスワードをサーバに送付し、毎回データベースに確認します。これは古典的な方法で、ブラウザのダイアログボックスにユーザ名とパスワードを入力する手法が多く見られます。
たとえるならば、キャッシュカードのようなもので、毎回暗証番号を入れることに似ています。
3. ハッシュを利用する

ユーザ名とパスワードをログイン時のみに行うのはセッション管理に良く似ていますが、サーバに何らかのＩＤを残すことはしません。手法としては、サーバ側でサーバ暗号とユーザ名をハッシュ化しクライアントに知らせ、アクセスする際にはハッシュとユーザ名をサーバに通知します。サーバ側はサーバ暗号とユーザ名を再度ハッシュ化し、通知されたハッシュ値と比較して認証を行います。
その都度ユーザ名とパスワードを送る仕組みと異なり、パスワードは最初のみに限定して安全性を高めると共に、毎回データベースに確認する手間を省けます。

以上が、それぞれの解説です。
他にも、さまざまな方法がありますが、今回は３つだけの紹介とさせていただきます。
以下が、それぞれの特徴などをまとめた表です。

なお、詳しく書くことはできませんが、会員メニューの認証は３番目の「ハッシュを利用する」に近いものを採用しています。その為、セッション管理が無く、当該ブログで指摘しているようなセッション削除に関する問題は理論上発生しないということは、上記のとおりです。
この仕組みを採用した背景としては、会員メニューのページ毎に有効期限を指定したいということと、実際のサーバは複数に分かれておりセッションの管理が煩雑になることとの２点からです。このおかげで、クレジットカードは高頻度に、サービス一覧は低頻度にパスワードを再確認する仕組みを構築できています。さらに、会員メニュー、コントロールパネル、オンラインサインアップ、ＤＮＳゾーン編集、ドメインコンパネ等、さまざまなシステムへシングルサインオン可能な環境が構築できました。

ちなみに、この仕組みの危険な点として記した暗号の漏洩や詐称を防ぐべく、公開鍵暗号を利用した暗号化での実装を行っており、認証サーバ以外、会員メニューやレンタルサーバコントロールパネルを含めて、全てのサーバにおいて秘密鍵が含まれておらず、それらのサーバでクッキーの偽造はできません。
さらに、クッキーの中には会員ＩＤと発行日時、キーのインデックス以外の情報はほとんど入っておらず、当然のことながらパスワードなどの機密情報は全くありません。

ところで、高木浩光氏の指摘はとても的を射ており感心する限りですが、キーの有効性についてはキーのインデックス情報により対処ができるようになっており、古いキーの失効をさせることも可能です。
すなわち、時間情報とキーインデックスを公開鍵暗号によって詐称できない裏づけの元にクッキーを生成し、失効したキーインデックスのシリアル番号を登録しておくことにより、古いクッキーの無力化が図れるようになっています。

なお、唯一当社で考えなければならないこととしては、ページ毎の有効期限を再考することかと思っています。
例えば、レンタルサーバのコントロールパネルには、かなりの長時間にわたってクッキーの失効を抑制していますが、１ヶ月毎にパスワード再確認の必要性があるのかもしれません。
このあたりについては、皆様のお知恵をお借りしつつ、ポリシーの再検討をさせて頂きたく思っております。

まとめ

1. 認証にセッション管理は利用しておらず、セッションを破棄する仕組みはそもそも存在しない


2. クッキー(SID)の有効期間はコントロールできる仕組みであり、ページ毎に個別の期限を設けている


3. クッキー(SID)を選択的に無効化できる仕組みがサーバ側に備わっている（失効情報）


4. クッキー(SID)には会員ＩＤとキーインデックス（シリアル）、発行時間などが含まれており、詐称防止のために公開鍵暗号を用いている


5. 現在の有効期限を今より短くしないといけないページがあるのかもしれない（コンパネ等）


6. ログアウトを押しつつクッキーを保存する人は通常はおらず、居たとしても前述のように有効期限管理で代用可能（クッキーを破棄するログアウト方法は一般的）

以上、長文を最後までごらん頂き、ありがとうございました。
また、当該ブログの管理者様には深く感謝いたします。

今後とも、さくらインターネットのサービスをよろしくお願いします。

追記1 4/28
当該ブログの管理者様によって記事が追加されていました。
http://neta.ywcafe.net/000731.html
大変丁寧にご対応いただき、ありがとうございます。
ちなみに、「公開してくださってもかまいません」については、特に他意はなく(笑)、ほかの方にメールを送った際に『ブログで公開しても言いか』と返信されることがたまにあるので、書いただけでした。私的には、「セッションではないらしい」ということと「パスワード確認があるらしい」ということが、ほかのかたがたに伝われば、特に問題は無く、結局このエントリーもあるので、見解の発表はすでに達成できたと思っています。
なお、新しい記事で書かれていた有効期限は、たいへん有用かと思うので、実現できればいいなと思います。SIDに含まれるキー自体は１日で失効させて、利用者の方があらかじめ設定した期間に限ってパスワードなしでキーを更新していくなどの方法も取れるかもしれません。

私が担当したインターネットウィークでのチュートリアルも、無事終了しました。
少し消化不良気味でしたが、たくさんの方にお越し頂き、大変嬉しく思います。
関係する方々には大変ご協力を頂き、ありがとうござました。

家には、MAC MINIとiBookあわせて2台のMACがあります。
そのMACの間でデータのやり取りを考えていたのですが、今回はLAN経由より高速なIEEE1394(FireWire)経由での接続を試してみました。

ちなみに、FireWire経由で接続するための方法は非常に簡単です。
まず2台のMACを用意し、ＩＥＥＥ1394のケーブルで接続します。この際、機種によって小型の６ピンの際と、大型の９ピンの場合がありますから間違えないように用意してください。
接続ができれば、外付けハードディスクとして認識させる事にします。外付けハードディスクとして認識させるには、キーボードの「T」キーを押しながら電源を入れ、画面にFireWireマークが出れば完了です。（外付けハードディスクとして認識されている間は、そのMACでいっさい作業はできません）
後は、他方のMACにおいてデスクトップ上にFireWireマーク付きのMacintosh HDが出てくるのを待つだけです。

肝心の転送速度ですが、ターミナル上で単純にデータ転送を行った結果、11062839 bytes/secと出ました。100Mbpsフルと同じくらいの速さなので、うちのしょぼい100M-HUBを介した接続とは雲泥の差です。
2台以上のMACをお持ちの方は、ぜひお試しあれ。

最近トラックバックスパムが、以前にもまして迷惑しています。
そのため、トラックバックのスクリプト名を修正していました。

というのも、どこぞのサイトで、URL決めうちでスパムを送信しているらしいとのことで、スクリプト名を修正すれば大丈夫なんじゃないかなということで。

具体的な方法は以下をご覧ください。

オラクルについてのメモ
最近、販売管理システムが遅いので、システム担当の協力を得ながらチューンナップなどしています。

その中で、いくつかをまとめました。

お客様より blogtimes をインストールできないとのことでサポートに問い合わせがきていたらしく、技術が調べていたのですが、そんなに難しいのかなということで、自分でインストールを試みました。

ということで、さくらのレンタルサーバライトで利用するblogtimesです。

1. ダウンロードとインストール

http://nilesh.org/mt/blogtimes/ よりダウンロードします。
私の場合は、ZIP版のアーカイブをダウンロードし、Windows端末にて展開して、FFFTPにてアップロードしました。 アップロード先は、/home/kunihirotanaka/www/mt/plugins でしたが、場合に応じてパスは変更が必要です。 ちなみに、さくらのレンタルサーバでは、標準で必要なモジュール等が入っており、特に変更の必要はありませんでした。
2. テンプレートの編集

Movabletype のテンプレートを編集します。
私は、以下のように書きました。
<MTBlogTimes width="150" height="20">
 <img src="<$MTBlogTimesFileURL$>" width="<$MTBlogTimesWidth$>"
  height="<$MTBlogTimesHeight$>"
  border="0" alt="B L O G T I M E S" title="B L O G T I M E S" />
</MTBlogTimes>

3. 再構築して完成

あとは、再構築をする事により、画像が入ります。
※注意点
• プラグインはCGIじゃないので、先頭行にスクリプトパスを書く必要はありません。
• imgタグにおいて直接blogtimes.plへのパスを書いてはいけません。
  マクロ「$MTBlogTimesFileURL」を利用します。
とりあえず、マニュアルどおりにやれば、さくらのレンタルサーバでは問題なくインストールができるようですので、参考にして下さい。

ゴールデンウィークなのに、することなく家でプログラミング。
会社で使うプログラムの新調に大忙しです。

最近は、社内の開発力もだいぶ上がってきて、以前より信頼できるようになりましたが、
何も無いところからの開発はまだまだ未完。
頑張って引き継いでいかなければなりませんねぇ。

東京出張から帰ってきました。

で、今回はネットワークの話。

うちの会社では、先月からコア部に10Gbpsのイーサーネットを導入しているわけですが、
周辺部に関しても10Gへのアップグレードをすべく検討をしております。

現在利用しているFoundry NetIron400に加えて、先日導入したForce10、
検証中の Procket や HitachiのGR4000 それに NetIron40G等々、
多数の個性をもったルータたち。
今日も、とある代理店が見積もりを持って、アピールしていってくれましたが、
値段が値段だけに、簡単には決断できません。
機器選定も大変なものです。

ちなみに、現在うちの東京第三データセンター（池袋）からKDDI大手町ビルまでは、
キャリア冗長を採った上で、10Gbps×2本の構成になっています。
半年くらいは、このままでもつでしょうかね・・・。