GoDaddy から Google Domains へ

say — 2019-10-12T18:04:08+09:00

移管した。安かったから。 ]]>

テスト

say — 2019-10-12T16:39:28+09:00

まだ使えるか、テスト ]]>

Internet Middleman

say — 2014-05-21T08:27:22+09:00

NANOGのMLでも話題になってたやつ。

アメリカだと選択肢が少ないから eyeball ISP の力が相対的に強いんですかね。

起
“Chicken” | A Game Played as a Child and by some ISPs with the Internet | Beyond Bandwidth
http://blog.level3.com/global-connectivity/chicken-game-played-child-isps-internet/
要約「Comcastがpeerじゃなくて金払えとか言って来るのマジむかつく。お客さーん、ビデオが止まるのはお宅のプロバイダーのせいですよー。」(注: Level3 はCDN事業者でもある)

承
Observations of an Internet Middleman | Beyond Bandwidth
http://blog.level3.com/global-connectivity/observations-internet-middleman/
要約「俺らまじデカイし(peerとか合計13Tbpsだし)、すげー金かけてるからお客さんがインターネット使えてるし、だからComcastムカつく」

転
Level3 is without peer, now what to do?
http://www.cringely.com/2014/05/06/14890/
要約「最近はややこしいから古き良き時代に戻れるといいののね」

An 'internet middleman' calls out six ISPs for letting connections slow down
http://www.engadget.com/2014/05/05/level-3-internet-middlemen/
要約「ガジェット好き」

結は知らない。 ]]>

FreeBSD 9.1-RELEASE reboot issue

say — 2013-07-11T22:59:21+09:00

しばらく前から FreeBSD 9.1-RELEASE-p4 の箱がリブートしない(All buffers synced.
の後で止まっちゃう)ので困ってた。(-p4 より以前から。たぶん、9.1 になった時から)

root@host:/root # reboot
Jul 10 10:06:27 host reboot: rebooted by root
Jul 10 10:06:27 host syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done
All buffers synced.
Uptime: 8h1m32s
usbus0: Controller shutdown
uhub0: at usbus0, port 1, addr 1 (disconnected)
usbus0: Controller shutdown complete
usbus1: Controller shutdown
uhub1: at usbus1, port 1, addr 1 (disconnected)
usbus1: Controller shutdown complete
usbus2: Controller shutdown

こんな感じで止まってる。

てっきりハードウェアの問題かと思って放っておいたんだけど、ふと思いついてちょっと "freebsd reboot stall usbus
controller shutdown" とかでググってみたところ、kern/172952: 9.1
hangs on reboot after all buffers synced が見つかった。これによると 9.1 で ZFS
な箱が同じようにリブートしないという問題らしい。ログを読んでいくとパッチが提案されており、9-stable にすでに commit されてるらしい。

そこで、さくっと svnup stable して、9-stable に上げてみた。(途中 xinstall
のコンパイルに失敗するとか関係ない穴にはまったけど、src 全体を svnup で取り直したらなおった。)

期待を込めて(複数回)リブートしたけど、まだダメだった。

root@host:~ # reboot
Jul 11 22:26:59 host reboot: rebooted by root
Jul 11 22:27:00 host syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done
All buffers synced.
Uptime: 9m8s
usbus0: Controller shutdown
uhub0: at usbus0, port 1, addr 1 (disconnected)
usbus0: Controller shutdown complete
usbus1: Controller shutdown
uhub1: at usbus1, port 1, addr 1 (disconnected)
usbus1: Controller shutdown complete
usbus2: Controller shutdown
uhub2: at usbus2, port 1, addr 1 (disconnected)
ugen2.2:  at usbus2 (disconnected)
umass0: at uhub2, port 3, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3
refs

こんな感じで止まっちゃう。メッセージは変わったけど、相変わらずリブートしない。

そこで、再度 "freebsd zfs usb reboot failure" とかでググったところ、Problem with shutdown and
external storage のスレッドが見つかり、最後のポストにある
hw.usb.no_shutdown_wait=1
を試したところ、ビンゴ！ついに無事リブートするようになった。

9.1 にもなってソフトウェアの問題とは思いもしなかった(しかも、確か 9.0 の時は問題は起こってなかった)ので、ここに到達するまで時間がかかった。

すっきり。
]]>

USB外付けディスクと ZFS

say — 2013-07-10T15:17:06+09:00

USB外付けディスク ( WD
Elements 2TB Desktop External Hard Drive ) をZFSで使ってると、しょっちゅう CHECKSUM
エラーが報告されるから、何も根拠はないけど、以下を追加してカーネルを入れ替えてみた。

/usr/src/sys/dev/usb/usbdevs:
product WESTERN ELEMENTS 0x1021 Elements External HDD

/usr/src/sys/dev/usb/quirk/usb_quirk.c:
USB_QUIRK(WESTERN, ELEMENTS, 0x0000, 0xffff, UQ_MSC_NO_SYNC_CACHE),
]]>

sudo tmutil disablelocal

say — 2012-12-05T17:46:30+09:00

done. ]]>

Disable NetBIOS on Mac OS X

say — 2012-12-03T11:06:49+09:00

--- com.apple.netbiosd.plist.orig       2012-12-03 11:02:23.000000000 +0900
+++ com.apple.netbiosd.plist            2012-11-27 15:52:56.000000000 +0900
@@ -3,9 +3,9 @@
 
 
        EnableTransactions
-       
-       Disabled
        
+       Disabled
+       
        Label
        com.apple.netbiosd
        ProgramArguments

And

# sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist

]]>

au iPhone 4S の請求

say — 2012-11-05T17:03:00+09:00

■ 毎月の請求

1,960	基本使用料 (プランZシンプル)
-980	誰でも割
5,460	ISフラット
315	IS NET
0	分割支払金
-2,140	毎月割
-980	男子割 (MNP)
3,635	合計

■ 請求書上での表記

914	(1960 - 980)/1.05-20 (基本使用料 - 誰でも割 - Web請求)
5,500	(5460+315)/1.05
-2,972	(毎月割 + 男子割)/1.05

]]>

au iPhone 5 の請求

say — 2012-11-05T16:41:44+09:00

■ 毎月の請求

1,960	基本使用料 (LTEプラン)
-980	誰でも割
5,460	LTEフラット
315	LTE NET
2,570	分割支払金
-2,570	毎月割
-980	男子割 (MNP)
5,775	合計

■ 請求書上での表記

934	(1960 - 980)/1.05 (基本使用料 - 誰でも割)
5,500	(5460+315)/1.05
-3,381	(毎月割 + 男子割)/1.05

]]>

Connecting Cisco console server to BayTech RPC3

say — 2012-08-25T05:55:50+09:00

Connecting Cisco 2600/2800/3600 async (CAB-OCTAL-ASYNC) to BayTech RPC3 console port.

It needs to use specially crafted cable. Pinouts on each end is explained here.
http://www.baytech.net/support/cable_adapters.shtml
http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a00801c9a10.shtml

Basically what you need is this.
http://www.baytech.net/cgi-bin/showprod?prod=RJ08X007-07

If you're using standard Ethernet cable which looks like this:

(left to right)
1 Orange white
2 Orange
3 Green white
4 Blue
5 Blue white
6 Green
7 Brown white
8 Brown

Then the other end (which connects to RPC3) should look like this:

(left to right)
1 Orange
2 Blue white
3 Orange white
4 Green white
5 Green
6 Brown
7 Blue
8 Brown white

Which means:

1 - 7 (Brown white)
2 - 4 (Blue)
3 - 8 (Brown)
4 - 6 (Green)
5 - 3 (Green white)
6 - 1 (Orange white)
7 - 5 (Blue white)
8 - 2 (Orange)

]]>

limiting root login for rsync

say — 2012-07-31T04:42:46+09:00

Set "PermitRootLogin forced-commands-only" in /etc/ssh/sshd_config and,

command="rsync --server -vulogDtpre.iLsf --delete . /backup",no-pty,no-agent-forwarding,no-port-forwarding ssh-rsa ssh-rsa xxxxx

in ~root/.ssh/authorized_keys. ]]>

fio

say — 2012-07-28T02:31:09+09:00

http://rewse.jp/blog/p/3283 の seqread.fio と同じテストをやってみた。

設定ファイルはこう。

[seqread]
readwrite=read
blocksize=1m
size=1g
directory=/root
direct=1
loops=5

結果はこんな感じ。

Target	bw	IOPS
内蔵ディスク1	129 MB/s	125
内蔵ディスク2	96 MB/s	93
外付け(USB2.0)	36 MB/s	35
お名前.com (virtio)	326 MB/s	318
お名前.com	203 MB/s	198
ServersMan@VPS	2 MB/s	1

元のページの方の結果はこの通り。

seqread: (groupid=0, jobs=1): err= 0: pid=11993
  read : io=5120.0MB, bw=128587KB/s, iops=125 , runt= 40773msec
    clat (msec): min=6 , max=201 , avg= 7.95, stdev= 5.06
     lat (msec): min=6 , max=201 , avg= 7.95, stdev= 5.06
    bw (KB/s) : min=46916, max=148317, per=100.45%, avg=129168.97, stdev=18220.10
  cpu          : usr=0.00%, sys=0.13%, ctx=5173, majf=0, minf=283
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued r/w/d: total=5120/0/0, short=0/0/0

     lat (msec): 10=95.55%, 20=1.04%, 50=3.38%, 250=0.04%

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=128587KB/s, minb=131673KB/s, maxb=131673KB/s, mint=40773msec, maxt=40773msec

Disk stats (read/write):
  sdd: ios=11566/204, merge=12732/7, ticks=61892/38088, in_queue=95940, util=97.95%

同じディスクを使って FreeBSD 9.0 上で行なった結果はこの通り。当たり前だけどほとんど変わらない。

ada0 at ata2 bus 0 scbus1 target 0 lun 0
ada0:  ATA-8 SATA 3.x device
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4

seqread: (g=0): rw=read, bs=1M-1M/1M-1M, ioengine=sync, iodepth=1
2.0.8
Starting 1 process
seqread: Laying out IO file(s) (1 file(s) / 1024MB)
Jobs: 1 (f=1): [R] [100.0% done] [104.4M/0K /s] [104 /0  iops] [eta 00m:00s]
seqread: (groupid=0, jobs=1): err= 0: pid=100860
  read : io=5120.0MB, bw=123650KB/s, iops=120 , runt= 42401msec
    clat (usec): min=479 , max=61769 , avg=8275.20, stdev=4561.82
     lat (usec): min=479 , max=61770 , avg=8275.67, stdev=4561.88
    clat percentiles (usec):
     |  1.00th=[  502],  5.00th=[  516], 10.00th=[  580], 20.00th=[ 8096],
     | 30.00th=[ 8640], 40.00th=[ 9536], 50.00th=[ 9664], 60.00th=[10176],
     | 70.00th=[10176], 80.00th=[10304], 90.00th=[10688], 95.00th=[10688],
     | 99.00th=[19840], 99.50th=[20864], 99.90th=[44800], 99.95th=[51456],
     | 99.99th=[61696]
    bw (KB/s)  : min=90934, max=1552384, per=95.78%, avg=118435.81, stdev=161443.26
    lat (usec) : 500=0.74%, 750=18.93%, 1000=0.31%
    lat (msec) : 10=37.38%, 20=41.80%, 50=0.76%, 100=0.08%
  cpu          : usr=0.14%, sys=13.09%, ctx=37013, majf=0, minf=261
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=5120/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=123649KB/s, minb=123649KB/s, maxb=123649KB/s, mint=42401msec, maxt=42401msec

もう一個のハードディスク。少し遅い。

ada1 at ata3 bus 0 scbus2 target 1 lun 0
ada1:  ATA-7 SATA 2.x device
ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad7

seqread: Laying out IO file(s) (1 file(s) / 1024MB)
Jobs: 1 (f=1): [R] [100.0% done] [77436K/0K /s] [75 /0  iops] [eta 00m:00s]
seqread: (groupid=0, jobs=1): err= 0: pid=103259
  read : io=5120.0MB, bw=96067KB/s, iops=93 , runt= 54575msec
    clat (usec): min=472 , max=58292 , avg=10652.27, stdev=5483.74
     lat (usec): min=472 , max=58293 , avg=10652.84, stdev=5483.83
    clat percentiles (usec):
     |  1.00th=[  490],  5.00th=[  516], 10.00th=[  556], 20.00th=[10048],
     | 30.00th=[12224], 40.00th=[12352], 50.00th=[12352], 60.00th=[12352],
     | 70.00th=[12480], 80.00th=[13888], 90.00th=[14016], 95.00th=[14016],
     | 99.00th=[22400], 99.50th=[22400], 99.90th=[38144], 99.95th=[38144],
     | 99.99th=[58112]
    bw (KB/s)  : min=73142, max=1605632, per=96.22%, avg=92434.55, stdev=149105.32
    lat (usec) : 500=1.41%, 750=18.52%, 1000=0.06%
    lat (msec) : 20=77.05%, 50=2.95%, 100=0.02%
  cpu          : usr=0.09%, sys=10.21%, ctx=38148, majf=0, minf=261
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=5120/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=96067KB/s, minb=96067KB/s, maxb=96067KB/s, mint=54575msec, maxt=54575msec

お名前.com VPS(KVM)(2GBプラン)上で virtio を有効にした上で行なったのがこれ。3倍弱速い。すごく速いです。

vtblk0:  on virtio_pci1
vtblk0: 204800MB (419430400 512 byte sectors)

seqread: (g=0): rw=read, bs=1M-1M/1M-1M, ioengine=sync, iodepth=1
2.0.8
Starting 1 process
seqread: Laying out IO file(s) (1 file(s) / 1024MB)
Jobs: 1 (f=1): [R] [100.0% done] [479.7M/0K /s] [479 /0  iops] [eta 00m:00s]
seqread: (groupid=0, jobs=1): err= 0: pid=100517
  read : io=5120.0MB, bw=325807KB/s, iops=318 , runt= 16092msec
    clat (usec): min=260 , max=73811 , avg=3092.02, stdev=3514.33
     lat (usec): min=269 , max=73820 , avg=3103.96, stdev=3514.25
    clat percentiles (usec):
     |  1.00th=[  318],  5.00th=[ 1624], 10.00th=[ 1688], 20.00th=[ 1752],
     | 30.00th=[ 1816], 40.00th=[ 1896], 50.00th=[ 1976], 60.00th=[ 2064],
     | 70.00th=[ 2224], 80.00th=[ 2736], 90.00th=[ 6112], 95.00th=[10560],
     | 99.00th=[18816], 99.50th=[21632], 99.90th=[31616], 99.95th=[36608],
     | 99.99th=[74240]
    bw (KB/s)  : min=79712, max=557056, per=92.45%, avg=301222.97, stdev=149712.28
    lat (usec) : 500=1.50%
    lat (msec) : 2=52.07%, 4=33.42%, 10=7.23%, 20=5.00%, 50=0.76%
    lat (msec) : 100=0.02%
  cpu          : usr=0.34%, sys=15.72%, ctx=7032, majf=4, minf=262
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=5120/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=325806KB/s, minb=325806KB/s, maxb=325806KB/s, mint=16092msec, maxt=16092msec

virtio使わなかったらこう。virtio使った時より30%くらい遅い。

ada0 at ata1 bus 0 scbus1 target 0 lun 0
ada0:  ATA-7 device
ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
ada0: 204800MB (419430400 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad2

seqread: (groupid=0, jobs=1): err= 0: pid=100401
  read : io=5120.0MB, bw=202866KB/s, iops=198 , runt= 25844msec
    clat (msec): min=2 , max=85 , avg= 5.01, stdev= 5.80
     lat (msec): min=2 , max=85 , avg= 5.02, stdev= 5.80
    clat percentiles (usec):
     |  1.00th=[ 2480],  5.00th=[ 2576], 10.00th=[ 2672], 20.00th=[ 2864],
     | 30.00th=[ 3088], 40.00th=[ 3568], 50.00th=[ 3792], 60.00th=[ 3888],
     | 70.00th=[ 3984], 80.00th=[ 4192], 90.00th=[ 7392], 95.00th=[13760],
     | 99.00th=[33024], 99.50th=[43264], 99.90th=[61696], 99.95th=[77312],
     | 99.99th=[85504]
    bw (KB/s)  : min=80000, max=299008, per=96.87%, avg=196517.25, stdev=51283.94
    lat (msec) : 4=70.98%, 10=21.66%, 20=4.57%, 50=2.50%, 100=0.29%
  cpu          : usr=0.17%, sys=7.35%, ctx=7767, majf=4, minf=276
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=5120/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=202866KB/s, minb=202866KB/s, maxb=202866KB/s, mint=25844msec, maxt=25844msec

ついでに ServersMan@VPS(Entry)でも実行した。すごく遅いです。

seqread: (groupid=0, jobs=1): err= 0: pid=627
  read : io=1024.0MB, bw=2023.4KB/s, iops=1 , runt=2591595msec
    clat (msec): min=9 , max=5747 , avg=506.10, stdev=609.76
     lat (msec): min=9 , max=5747 , avg=506.10, stdev=609.76
    clat percentiles (msec):
     |  1.00th=[   41],  5.00th=[   99], 10.00th=[  111], 20.00th=[  153],
     | 30.00th=[  184], 40.00th=[  210], 50.00th=[  212], 60.00th=[  241],
     | 70.00th=[  302], 80.00th=[  996], 90.00th=[ 1696], 95.00th=[ 1696],
     | 99.00th=[ 1795], 99.50th=[ 1795], 99.90th=[ 2180], 99.95th=[ 2245],
     | 99.99th=[ 5735]
    bw (KB/s)  : min=  178, max=11861, per=100.00%, avg=3141.50, stdev=2616.53
    lat (msec) : 10=0.08%, 20=0.23%, 50=0.96%, 100=5.04%, 250=55.68%
    lat (msec) : 500=17.40%, 750=0.43%, 1000=0.18%, 2000=19.84%, >=2000=0.16%
  cpu          : usr=0.01%, sys=0.10%, ctx=44149, majf=0, minf=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=5120/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=2023KB/s, minb=2023KB/s, maxb=2023KB/s, mint=2591595msec, maxt=2591595msec

外付けのUSB2.0ハードディスクだとこんな感じ。

da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0:  Fixed Direct Access SCSI-4 device 
da0: 40.000MB/s transfers
da0: 1907727MB (3907024896 512 byte sectors: 255H 63S/T 243201C)

seqread: (groupid=0, jobs=1): err= 0: pid=103304
  read : io=5120.0MB, bw=36294KB/s, iops=35 , runt=144455msec
    clat (usec): min=509 , max=642934 , avg=28202.87, stdev=25625.75
     lat (usec): min=510 , max=642934 , avg=28203.62, stdev=25625.79
    clat percentiles (usec):
     |  1.00th=[  620],  5.00th=[  740], 10.00th=[  852], 20.00th=[15040],
     | 30.00th=[29568], 40.00th=[29824], 50.00th=[29824], 60.00th=[29824],
     | 70.00th=[30080], 80.00th=[30080], 90.00th=[41216], 95.00th=[53504],
     | 99.00th=[95744], 99.50th=[185344], 99.90th=[358400], 99.95th=[411648],
     | 99.99th=[643072]
    bw (KB/s)  : min= 3043, max=954368, per=90.51%, avg=32850.75, stdev=56253.15
    lat (usec) : 750=5.31%, 1000=8.89%
    lat (msec) : 2=5.70%, 4=0.08%, 20=0.04%, 50=74.41%, 100=4.59%
    lat (msec) : 250=0.76%, 500=0.20%, 750=0.02%
  cpu          : usr=0.09%, sys=5.49%, ctx=56527, majf=0, minf=261
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=5120/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=5120.0MB, aggrb=36294KB/s, minb=36294KB/s, maxb=36294KB/s, mint=144455msec, maxt=144455msec

]]>

ZFS Compression

say — 2012-07-21T04:26:03+09:00

当たり前かもしれないけど、ZFS で compress してる場合、ls は圧縮「前」のファイルのサイズを返すけど、du は圧縮「後」の使用量を表示する (du も zfs list も圧縮「後」の値)

% zfs list -o name,mountpoint,used,avail,refer,compression,exec,setuid zroot/root/home
NAME             MOUNTPOINT   USED  AVAIL  REFER  COMPRESS  EXEC  SETUID
zroot/root/home  /home       34.0G   156G  34.0G      gzip    on      on
% cd /home
% dd if=/dev/zero of=10G.bin bs=1m count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 13.024897 secs (805055127 bytes/sec)
% ls -lh
total 1
-rw-r--r--  1 say  say   9.8G Jul 21 04:15 10G.bin
% zfs list -o name,mountpoint,used,avail,refer,compression,exec,setuid zroot/root/home
NAME             MOUNTPOINT   USED  AVAIL  REFER  COMPRESS  EXEC  SETUID
zroot/root/home  /home       34.0G   156G  34.0G      gzip    on      on (変化無し)
% du -sh
2.0k    .
%

ちなみに IMAP(maildir) と Mew のフォルダが置いてある home ディレクトリを gzip で圧縮したら、23GB→8.4GB (-14.6GB 37%) と 44GB→15GB (-29GB 34%) という感じに圧縮できた。テキストファイルだけだから圧縮が効きやすいんだけど、44GB も節約できたのはディスク容量に制約のあるVPS上では嬉しい。 ]]>

お名前.com VPS(KVM)障害

say — 2012-07-20T14:30:59+09:00

お試し中のお名前.com VPS(KVM)が落ちた。(以下、時間はすべて JST)

http://www.onamae-server.com/support/news/detail.php?nid=12859

　サーバーサービス 不具合のお知らせ

お名前.comレンタルサーバーをご利用いただきまして、誠にありがとうございます。

下記日時におきまして、一部サービスに障害が発生しておりました。
ご利用のお客様には大変ご不便をおかけ致しましたことを深くお詫び
申し上げます。


　発生日時　：　2012年07月20日(金) 06時07分頃
　復旧日時　：　2012年07月20日(金) 13時00分頃
　対象　　　：　VPS(KVM)ご利用の一部のお客様（cnode-a1104）
　影響/詳細 ：　収容サーバの高負荷により、VPSに接続ができない
　　　　　　　　障害が発生いたしました。
　　　　　　　　
　　　　　　　　本障害の復旧作業に伴いVPSの再起動を実施させて
　　　　　　　　いただいております。

発生時間が 6am からのようだが、実際に影響が出たのは 8:12am だった。8:12am に一度落ちて、8:39am に上がってきたけど、9:59am に再度落ちてる。その後上がってきたのが 12:33pm だった。

障害発生から本復旧まで実質合計4時間21分。(8:56am くらいに一度復旧してることに気づいて作業を始めたけど、また 10am くらいに落ちたログも残ってた)

以下は syslog からの抜粋

Jul 20 08:12:37 host sshd[1205]: Received signal 15; terminating.
Jul 20 08:12:37 host kernel: Stopping cron.
[...]
Jul 20 08:12:38 host syslogd: exiting on signal 15
Jul 20 08:39:19 host syslogd: restart
Jul 20 08:39:19 host syslogd: kernel boot file is /boot/kernel/kernel
Jul 20 08:39:19 host kernel: Copyright (c) 1992-2012 The FreeBSD Project.
[...]
Jul 20 09:59:18 host sshd[1201]: Received signal 15; terminating.
Jul 20 09:59:18 host kernel: Stopping cron.
Jul 20 09:59:18 host kernel: Stopping sshd.
[...]
Jul 20 09:59:19 host kernel: Waiting for PIDS: 1100
Jul 20 09:59:19 host kernel: .
Jul 20 09:59:19 host syslogd: exiting on signal 15
Jul 20 12:33:10 host syslogd: restart
Jul 20 12:33:10 host syslogd: kernel boot file is /boot/kernel/kernel
Jul 20 12:33:10 host kernel: Copyright (c) 1992-2012 The FreeBSD Project.
Jul 20 12:33:10 host kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

ちなみにいずれの場合もいきなり落ちてるわけじゃなく、(なぜか)ちゃんと shutdown シーケンスが走ってる。これはファイルの保護とか考えるとありがたかった。

障害発生中はコントロールパネル(https://cp.myvps.jp/)にログインしても、コンソールはつながらないし、再起動、シャットダウン、電源断、などの操作も受け付けなかった。(しかもサーバのステータスは「稼働中」のままだった)

障害情報を見る前にサポートに電話しちゃったけど、会員ID(7桁の数字)を伝えたらすぐに故障のことを教えてくれた。24時間電話受付をしてくれるのは安心感が高い。(例えばさくらは10am〜6pmで土日祝休み) (まぁでも、電話で得られる情報ってウェブに載ってる情報とほぼ等価なことが多いからあんまり意味はない場合が多いけどね)

しばらくしたら「ログインに失敗しました。ログインIDとパスワードをご確認ください。」と表示されてコントロールパネルにもログインできなくなった。(故障対応の一環として一時的に使えなくしたのかな？)

その後 12:32pm 頃にサポート担当の方から「復旧したと思う」という電話が(わざわざ)かかってきた。聞いてみると「なぜかVMの起動に時間がかかったんだけど、何か心当たりはあるか？」という問い合わせだった。残念ながら何も心当たりはなかったので申し訳なかったけど、電話までしてきて対応(原因究明)する姿勢は素晴らしい。

というわけで、まだお試し中なので特に困ったことはなかった上に、(まだ課金ユーザじゃないにも関わらず)サポートの体制も悪くないことが分かったので、むしろ収穫だったと言えるかな。

(ちなみに、障害中に Twitter で「お名前 VPS」とかで検索したんだけど何も引っかからなかった。理由は 1) サービスのユーザが少ない 2) 当該ホストにはユーザが少ない 3) 普通は気にしない 4) こんなことわざわざtweetしない 5) 気づかない 6) その他のどれだろう。)

]]>

StartSSL certificate for Sendmail as client cert

say — 2012-07-20T06:34:15+09:00

StartSSLで取得した証明書を Sendmail のクライアント証明書に設定("confCLIENT_CERT")して STARTTLS で認証できるようになったかと思いきや、

Jul 19 16:53:10 server sm-mta[7174]: STARTTLS=server, relay=hoge.example.com [x.x.x.x], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256

というログが出て認証に失敗した。

理由が分からなかったのでサーバー側で sendmail.cf の

O LogLevel=9

を14に変更して sendmail を再起動。

再度メールを送ったところ今度は

Jul 19 16:55:09 server sm-mta[7174]: STARTTLS: TLS cert verify: depth=0 /description=xxxxxxxxxxx/C=JP/CN=hoge.example.com/emailAddress=mail@example.com, state=0, reason=unsupported certificate purpose

というログが残った。

ちょっとググってみるとどうやら証明書の使い道が適当じゃないのが原因のようだ。

$ openssl x509 -noout -purpose -in hoge.example.com.pem
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

の "SSL client" のところが Yes になってないとこの目的には使えないらしい。

どうも https://www.startssl.com/?app=40 を見る限り、有償だと使えそう("Server-Client Authentication" がそれじゃないかな)だなぁ。とりあえず問い合わせてみた。

(追記：contact formから問い合わせたらすぐに返事がきた。結論はやっぱりクライアント証明書には有償の Class2/3 certificate を使え、ということだった。) ]]>

clicklog