KD22で遊ぶ

KD22で遊ぶ

■はじめに

2014/08/18
KAICHO: s_naray[at]yahoo[dot]co[dot]jp
※SPAM防止中

本書では、ShuttleのNAS「KD22」 の情報を細々と掲載する。 例によって2Drive NASをRAID1以外で使うなんて怖くて怖くて!という理由で、 ここでは基本的にRAID1(ミラーリング)構成 のみを対象とし、RAID0などその他のモードは試していないことに注意。 ここで示した殆どの情報は、KD20、KD21でも共通に使えるはず。

なお、ファームウェアは2.02.20140721(2014/08/18現在最新)で確認している。

KD22は色々エンジニア心をくすぐる設計なんで、ずっと中を見てみたいと思ってた。 ら、Tsukumoが新品をお安く売ってた(※つまりモノがあんまよくないという証左)ので、 ヒャッハー!ということで購入してしまったよ!13000円で本体入手できたと思えば まぁ遊びとしてはよかったんじゃなかろうか、と。 HDL2-Aでは大体もう遊び尽くしちゃったしー

■おやくそく

このページの情報は一切無保証で、誤っている可能性もあることを 先に了承すること。このページを見て操作した挙句、アナタに何か不利益な ことが起こったとしても、我輩は一切それに関知しない。何もかも自己責任。

■内部情報

●概要

本機は、ARM Linuxを採用している。
内部にフラッシュメモリがあり、OS起動用の領域はそこに格納されている。 従って、二つのHDDが両方破損しても、起動はできるしWebUIでアクセスも可能。 このへんはHDL2-Aに比較するとよくできててユーザに優しいところ。

初期状態(RAID1でフォーマット)でのCrystalDiskMarkの結果はこんな。writeの方が 高速なのが、つまり「書き込みキャッシュされてるから瞬断には弱い」ということを 如実に表している。UPSが欲しいところ。
HDL2-Aと同じ安物HUB経由してるが、それにしても110MB/s(RAID1かどうかは不明)とか ゆってんだからもう少し頑張ってほしかった。 これだと(HDDの性能差とか考慮したとしても)HDL2-Aの方がオトクな気がする。 向こうは4TBx2のHDDは公式には載せられないけれど。

電源Onからアクセス可能になるまでは一分15秒程度、結構起動は高速。 少なくともHDL2-Aみたいに三分もかかったりはしない。助かる。 停止も一分以内には止まるのでよろし。

…ところで停止方法は(WebUI経由じゃないときは)電源ボタン長押しでいいのかね? そして電源ボタンちょっと押しの時の動作(電源ランプは消えるが動いてるっぽい)は なんなんだ…?。マニュアルにも書いてないようなんだけど。

●起動時情報

KD22については、世界にもほとんど情報が転がってない。 ハックはそんなに難しくないから、もう少し情報あってもいいと思うけどな。 最終的にゴニョゴニョしてみたら、ファームウェア(2.02.20140721)の情報は以下だった ので書いておく。

  • Boot: u-Boot
  • Distribution: 多分Debianベース
  • kernel: 3.2.24
  • CPU: Marvel 86F6707 1.2GHz
  • Mem: 512MB

起動時のdmesgはこちら。色々わかって面白い。 ttyS0が存在するし、kernel commandlineにconsole=ttyS0,115200があるから、 デフォルトでシリアルに情報は出てるんだね、というのがわかったり。ウッホゥ。

でも残念、SATAは3Gbps接続なんですな。6Gbpsはやっぱ無理かー。 SSDに交換して爆速!とかちょっとやってみたかった(※SMB経由なら意味がない)。

●内蔵Flash情報

ちょっとゴニョゴニョした結果、以下のように構成されていることが分かった、 四つflashがあって、それぞれ以下のようにイメージが記録されている。

  • /dev/mtd0 : u-boot イメージ
  • /dev/mtd1 : カーネルイメージ(uImageそのまま)
  • /dev/mtd2 : initrd(u-bootの64byteヘッダ + gzip圧縮されたinitrd(ext2))
  • /dev/mtd3 : root file system(UBIFS)

実際KD22上で/proc/mtdを見るとこんなカンジ。

> cat /proc/mtd  dev:    size   erasesize  name  mtd0: 00100000 00010000 "spi_flash"  mtd1: 00800000 00020000 "kernel"  mtd2: 00600000 00020000 "initrd"  mtd3: 07200000 00020000 "rootfs"  

rootfs(/dev/mtd3)は、rootfs.ubiファイルをそのまま流し込んだもの。 ゴニョゴニョして入手したrootfs.ubiファイルは、 以下のような手順を実行することで、 nandsimモジュールとubifsを使って(nandsimとubifsが使用可能な)フツーのLinux上で mount可能。我輩はCentOS6で確認した。 mtd-utilsどっかから入手したりしないといけなくて少々面倒だけど。
あ、(KD22ではなく)KD21のrootfs.ubiはここから入手できたりする。中はほとんど同じなので見てみるといいかも。 そしてここからが大事な話なんだけど、実は中を見ると…うッ貴様は!?うわなにをするやめふじこ!(深刻なエラーが発生しました)。

# # 128MiB, 2048 bytes/page であることに注意  # modprobe nandsim first_id_byte=0xec second_id_byte=0xa1 third_id_byte=0x00 fourth_id_byte=0x15  # ubiformat -s 2048 -f /tmp/rootfs.ubi /dev/mtd0  # modprobe ubi  # ubiattach /dev/ubi_ctrl -m 0 -O 2048  # mount -t ubifs -r /dev/ubi0_0 /mnt  

フツーのLinux上でのmtdinfoとubinfoの出力はこんな。ここでは便宜上デバイス名が /dev/mtd0になってることに注意。

# mtdinfo /dev/mtd0 -u  mtd0  Name:                           NAND simulator partition 0  Type:                           nand  Eraseblock size:                131072 bytes, 128.0 KiB  Amount of eraseblocks:          1024 (134217728 bytes, 128.0 MiB)  Minimum input/output unit size: 2048 bytes  Sub-page size:                  512 bytes  OOB size:                       64 bytes  Character device major/minor:   90:0  Bad blocks are allowed:         true  Device is writable:             true  Default UBI VID header offset:  512  Default UBI data offset:        2048  Default UBI LEB size:           129024 bytes, 126.0 KiB  Maximum UBI volumes count:      128    # ubinfo -a  UBI version:                    1  Count of UBI devices:           1  UBI control device major/minor: 10:59  Present UBI devices:            ubi0    ubi0  Volumes count:                           1  Logical eraseblock size:                 126976 bytes, 124.0 KiB  Total amount of logical eraseblocks:     1024 (130023424 bytes, 124.0 MiB)  Amount of available logical eraseblocks: 0 (0 bytes)  Maximum count of volumes                 128  Count of bad physical eraseblocks:       0  Count of reserved physical eraseblocks:  10  Current maximum erase counter value:     3  Minimum input/output unit size:          2048 bytes  Character device major/minor:            250:0  Present volumes:                         0    Volume ID:   0 (on ubi0)  Type:        dynamic  Alignment:   1  Size:        1010 LEBs (128245760 bytes, 122.3 MiB)  State:       OK  Name:        rootfs  Character device major/minor: 250:1  

●ディスク構成概要

今回は、Seagate 4TB(ST4000DM000)と HGST 4TB(0S03361=HDS5C4040ALE630)をつっこんで構築してみた。この二つは いずれも同じセクタ数(=7814037168(512byte/Sectorの場合))なので、相互に 交換できて便利。

KD22でディスクをつっこんでRAID1で初期化すると、ディスクのパーティションは 以下のように作成された(Seagate側)。4TBなので最初からGPT。

# parted -s /dev/sda print  Model: ATA ST4000DM000-1F21 (scsi)  Disk /dev/sda: 4001GB  Sector size (logical/physical): 512B/512B  Partition Table: gpt    Number  Start   End     Size    File system  Name     Flags   1      16.8MB  226MB   210MB                primary  raid    2      226MB   331MB   105MB                primary          3      331MB   1405MB  1074MB               primary  raid    4      1405MB  4001GB  3999GB               DataVol  raid      

セクタ単位で表示するとこんなカンジ。スタートセクタは全て8で割り切れるので、 ちゃんと4KB/SectorのHDDにもコピーできる。ちうか、ST4000DM000って512byte/sector だったのん?partedからは見えないだけなのかな。

# parted -s /dev/sda u s print  Model: ATA ST4000DM000-1F21 (scsi)  Disk /dev/sda: 7814037167s  Sector size (logical/physical): 512B/512B  Partition Table: gpt    Number  Start     End          Size         File system  Name     Flags   1      32768s    442367s      409600s                   primary  raid    2      442368s   647167s      204800s                   primary          3      647168s   2744319s     2097152s                  primary  raid    4      2744320s  7814035455s  7811291136s               DataVol  raid   

パーティション構成は以下の通り。

  1. 1番目(210MB) : md1.2(RAID1) + ext2。設定ファイルとログ保存領域。なんでext3じゃないのか不明
  2. 2番目(105MB) : 使途不明。0フィルされていてファイルシステムも内容もない
  3. 3番目(1074MB): md1.2(RAID1) + swap。いわゆるスワップ領域
  4. 4番目(3999GB): md1.2 + xfs。データ領域

●ディレクトリ構成

フォーマット直後、4番目のデータパーティションを別のLinuxシステム上で確認 したら、disk と.omninas.tmpというディレクトリしか存在しなかった。そして、 .omninas.tmpの下にはTwonkyサーバ( DLNA サーバ)用のファイルが存在した。なるほどなるほど。 これ以下の具体的なファイルリストはヤバそうなので出さない。

# ls -al .  total 4  drwxr-xr-x  4 libuuid root   48 Jan  1  2013 .  drwxr-xr-x  4 root    root    0 Aug 18 03:31 ..  drwxrwxrwx  3 root    root   28 Aug 16 23:25 .omninas.tmp  drwxrwxrwx 19 root    root 4096 Aug 17 15:58 disk  total 4  # cd .omninas.tmp  # ls -al .  drwxrwxrwx 3 root    root   28 Aug 16 23:25 .  drwxr-xr-x 4 libuuid root   48 Jan  1  2013 ..  drwxrwxrwx 9 root    root 4096 Aug 17 00:29 .twonky  

DTCP-IPが同時にサポートされているかどうかは未調査。誰か我輩に 確認可能なREGZAとか送ってください。 あ、HDDは4TB以上でBlu-rayが読めるヤツがいいです(傲慢)。

●ディスク構成詳細…データパーティション

上で述べたように、データパーティションは4番目のでっかいパーティション。 ここは、LinuxのSoftwareRAID(md … Linux Multi-Disk)でRAID0またはRAID1を 構成した上でxfsでフォーマットされている

具体的には、md version 1.2が利用されており、パーティション先頭にこんな データがある(xxはUUIDなので削除)。md名称として、ホスト名+”:1″を書き込むみたい。 0x100000からはxfsが始まる。

# dd if=/dev/sda4 | hexdump -C  00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  *  00001000  fc 4e 2b a9 01 00 00 00  00 00 00 00 00 00 00 00  |.N+.............|  00001010  xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |................|  00001020  6b 64 32 32 2d 73 6e 61  72 61 79 2e 6d 79 64 6f  |kd22-snaray.mydo|  00001030  6d 61 69 6e 2e 63 6f 6d  3a 31 00 00 00 00 00 00  |main.com:1......|  00001040  b4 76 e2 50 00 00 00 00  01 00 00 00 00 00 00 00  |.v.P............|  00001050  f0 ce 96 d1 01 00 00 00  00 00 00 00 02 00 00 00  |................|  00001060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  *  00001080  00 08 00 00 00 00 00 00  00 d0 96 d1 01 00 00 00  |................|  00001090  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  000010a0  01 00 00 00 00 00 00 00  3f 15 dd 3f 77 ce 89 cd  |........?..?w...|  000010b0  2c cb 3a ef 2e c5 00 30  00 00 00 00 00 00 00 00  |,.:....0........|  000010c0  0c ef f0 53 00 00 00 00  02 00 00 00 00 00 00 00  |...S............|  000010d0  ff ff ff ff ff ff ff ff  dd 22 e6 ad 80 01 00 00  |........."......|  000010e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  *  00001100  00 00 01 00 fe ff fe ff  fe ff fe ff fe ff fe ff  |................|  00001110  fe ff fe ff fe ff fe ff  fe ff fe ff fe ff fe ff  |................|  *  00001400  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  *  00100000  58 46 53 42 00 00 10 00  00 00 00 00 3a 32 d9 de  |XFSB........:2..|  00100010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  (snip)  

0x1000からの “fc 4e 2b a9” が、mdのマジックナンバー。メジャー番号はその次の 4byte(=0x00000001)で、先頭から 0x1000(=4096)の位置にあるので、これは md version 1.2 であることがわかる。詳細知りたい人は RAID superblock formats参照。

このmdマジックナンバーは「パーティション先頭+4096byte」に存在する。 ということは、”mdadm –assemble /dev/md0 <デバイス>” でmdを有効にしない限り、 xfsでmountすることもできないということだ。しかも困ったことに、一方のHDDだけで mdを有効化すると、mdヘッダ中のctimeが変わってしまい、もう一方と整合性が 取れなくなってしまって、次にKD22に接続して電源Onした時に、 RAID0ならRAID崩壊、RAID1ならRAID再構築が自動的に開始されちゃうという めんどくささ。だから、よくわかんない状態でLinux PCに接続するとかしないほうが いいと思う。

ただ、md version 1.2であるおかげで、 ディスクサイズの上限は4TBをらくらく超えることができる。 このあたりはHDL2-Aよりもイイ。

■分解してみる

最初に言っておくが、「分解はしないほうがいい」。ポリシー的なこともあるし、 保証の話もあるが、それよりもなによりも、KD22の分解は異様に難しいから。 どうやっても本体に傷つけちゃうし、一部爪は絶対破損しちゃうし。 やっぱこう、世界にKD2xの分解記事がほとんどないのは、分解が難しいからだろうなぁ、と思う。 だから、 どうしてもファンが壊れて交換しないとだめだとか、そういう理由が無い限りは 分解しないことを強くおススメする。

…ということを前提に、以下分解手順とか。この手順は、KD20、KD21共に共通のはず。
でもなー、解析するためにシリアルポートがどこにあるかとか知りたいんだよなー…。

●ケース右ガワをはずす(1)

分解の最初にして最大の関門がコレ。正面向かって右側の板(後ろに回りこんでる)を 外すこと。これがもうケース叩き割りたくなるくらい難しい。 ネジ二本と爪で固定されてるんだが、爪の数が尋常じゃない。 コの字型のアルミケースが広がるのを防ぐための「広がるのを防ぐ爪」と、 ガワが外れるのを防ぐための「ガワを留める爪」の二種類があって、 それぞれが反対方向にガッチリハマっているため。 こんなの傷付けずにバラすの無理って!

まず、前面蓋の蝶番部分の奥に見えるネジを二本外す。 このネジは、フロントパネル(蓋じゃなくてHDD収める部分ね)と右ガワとケース内の プレス板の三つを固定させるために使われていて短い。 まぁコレは外すだけだから楽。

そしてここからが本番。 後で外したガワは見せるとして、実際には右ガワは後ろから外す。 後面の「アルミケース+プラスチックホルダとガワの間」にマイナスドライバなどを ツッコんで、赤印裏にある三つの爪(ガワからケース内部方向に向かって伸びている)を 外し、ネットワークとUSBの端子がガワに引っかかるのを注意深く避けながら、 矢印方向に向かって3mmくらいスライドさせる。

  • 爪は右ガワからケースの□型にハマっているので、この爪を外すには「右ガワをさらに後方に浮かす」ようにするとよい
  • なぜ3mmかというと、右側面にも爪がわんさか隠れているので、まだこれだけでは外れないから
  • なぜ矢印方向にスライドさせるのかというと、このガワの後面上下にそういうレールがあるから。無理に外そうとするとこのレールが割れる

ほらもうイヤになってきたでしょ!? この時点で、プラスチック部分にはマイナスドライバーで著しい傷がつくこと間違いなし。

●ケース右ガワをはずす(2)

側面から見ると、赤印部分の8箇所で、右ガワがケースに爪で固定されている。 こちらは爪の出方が背面とはオスメス逆で、 「ケースから出た爪が右ガワの□型にハマっている」ことに注意。 だから、こっちを外す時は、爪部分を狙ってまっすぐ「水平方向に」マイナスドライバーをネジこめれば綺麗に外れる。んだけど、まぁ無理。いくつかの爪が破損することは諦めるが吉。

というか、正直この爪は要らんかったんじゃないかと思う。 だってケース前方でネジで固定されてるんだから。分解させたくないのかしらん。 そりゃそうか。

外した右ガワを見るとこんなカンジ。もうこれが外れれば大体全部分解は 終わったものと考えていいんじゃないか。 「やり遂げた男の顔」になってもいいと思う。爪の位置を赤印で示した。 全部で11箇所。なんで素数なんだ。 前面の蓋は右ガワに付いているんですな。

やっぱ右ガワってハメ殺しだよなー、と思う。 ケースメーカーらしいといえばらしい複雑っぷり。箱根の寄木細工かぃ。

右ガワ背面を外したらこんなカンジ。全然分解できてないように見える…。 こっちは、背面側爪がメス(□型)であること、側面側がオスであることが、 写真から判るだろうか。

●前面パネルをはずす

前面パネルは比較的楽。爪に注意しつつ前方方向に引っ張れば外れる。 ただし、爪は相変わらずあるし脆いので、まぁ注意してくだされ。 スイッチと接続されたコネクタが向かって左下にある。 今回は面倒だから爪から外すだけにした。

●左ガワをはずす

左ガワ(コの字型のアルミケース部分+プラスチック)は、 前後二本ずつ、計四本の長いネジ(赤印…写真では既に抜いてあるけど)で固定されているだけ。 右ガワに比較すると異様に素直。 ただ、このネジは、HDDホルダと左ガワと左ガワに固定されてるプラスチック部分の三つを固定しているので、かなり長いことに注意。 特に後ろ側は、緩めるにもスゴい長いこと回さないとダメなんだよね。

この四本を抜き、ケースに貼られている「無線LANの基盤」をケースから剥がすと、 左ガワが外れる。 基盤は細いマイナスドライバを接着面にゆっくり入れていけば剥がれる。 シールも再利用可能。

●HDDホルダ部分のプレス板を分解する

マザーボードは底部にあり、ここからライザーでHDDのSATA端子が立ち上がっている。 HDDホルダ部分のプレス板は、底部とネジ4本でつながっているだけなので、 左右のネジ四本(プレス板に矢印がある)を外すことで分解できる。 無線LANのケーブルがギリギリの長さなので、切らないように注意。

外す前に、後部のファンの下、薄いシールド板部分の写真を撮っておくことをおススメする。 シールド板から爪が出てて、これが本体に「互い違いに」ハマっていて、 組み立てるときにどうハマっていたかがわかんなくなるため。 別に正確に組み立てなくても破損とかはないけど、 気持ちよく元通りに組み立てるには必要だと思う。 …とか書いておきながら、自分は写真撮るの忘れたという。

●マザーボードを眺める

やっとここまできたので、こころゆくまでマザーボードを眺めてみよう。 右下に「KD22」の刻印があるので、このマザーはわざわざKD22用に作成されたものだと いうことがわかる。Shuttleの本気度が伝わる一品。 右下に写ってる足は心霊現象じゃなくて我輩の足なのでご安心を。

本当は、内部解析用にシリアル端子とか無いかしら、と思ったのが分解の きっかけだったのだが、ざっと見たところそんなのはなさそう。 マザーボード背面を見る元気は既になかったので、今回はここまで。

■オマケ情報

●オマケ1:外向けに開いてるポート

KD22を普通に動かしつつ、別のマシンから、KD22が外向けにサービスしている ポートが無いか確認。sshで入ってLISTENをgrepしただけ。 結果見ると、TCPではtelnetもsshも使えないですな。アタリマエか。 UDPの開いてるポートが少ない!

kd22-snaray> netstat -anp  | grep "LISTEN|0.0.0.0:*"  tcp        0      0 ###.###.###.###:9443    0.0.0.0:*               LISTEN      20277/twonkyserver  tcp        0      0 127.0.0.1:9443          0.0.0.0:*               LISTEN      20277/twonkyserver  tcp        0      0 0.0.0.0:515             0.0.0.0:*               LISTEN      2764/lpd Waiting  tcp        0      0 0.0.0.0:59619           0.0.0.0:*               LISTEN      2694/responder  tcp        0      0 0.0.0.0:548             0.0.0.0:*               LISTEN      2325/afpd  tcp        0      0 0.0.0.0:3689            0.0.0.0:*               LISTEN      2732/mt-daapd  tcp        0      0 ###.###.###.###:9010    0.0.0.0:*               LISTEN      20277/twonkyserver  tcp        0      0 127.0.0.1:9010          0.0.0.0:*               LISTEN      20277/twonkyserver  tcp        0      0 127.0.0.1:4700          0.0.0.0:*               LISTEN      2326/cnid_metad  tcp        0      0 :::3200                 :::*                    LISTEN      3103/httpd  tcp        0      0 :::139                  :::*                    LISTEN      2310/smbd  tcp        0      0 :::80                   :::*                    LISTEN      3103/httpd  tcp        0      0 :::443                  :::*                    LISTEN      3103/httpd  tcp        0      0 :::445                  :::*                    LISTEN      2310/smbd  udp        0      0 ###.###.###.###:1030    0.0.0.0:*                           20277/twonkyserver  udp        0      0 127.0.0.1:1030          0.0.0.0:*                           20277/twonkyserver  udp        0      0 0.0.0.0:39469           0.0.0.0:*                           2731/mt-daapd  udp     8960      0 ###.###.###.###:1900    0.0.0.0:*                           20277/twonkyserver  udp        0      0 239.255.255.250:1900    0.0.0.0:*                           20277/twonkyserver  udp        0      0 ###.###.###.255:137     0.0.0.0:*                           2307/nmbd  udp        0      0 ###.###.###.###:137     0.0.0.0:*                           2307/nmbd  udp        0      0 0.0.0.0:137             0.0.0.0:*                           2307/nmbd  udp        0      0 0.0.0.0:42378           0.0.0.0:*                           2718/mDNSResponderP  udp        0      0 ###.###.###.255:138     0.0.0.0:*                           2307/nmbd  udp        0      0 ###.###.###.###:138     0.0.0.0:*                           2307/nmbd  udp        0      0 0.0.0.0:138             0.0.0.0:*                           2307/nmbd  udp        0      0 ###.###.###.255:8100    0.0.0.0:*                           2701/responder  udp        0      0 0.0.0.0:60105           0.0.0.0:*                           20277/twonkyserver  udp        0      0 0.0.0.0:5353            0.0.0.0:*                           20277/twonkyserver  udp        0      0 0.0.0.0:5353            0.0.0.0:*                           2731/mt-daapd  udp        0      0 0.0.0.0:5353            0.0.0.0:*                           2718/mDNSResponderP  unix  2      [ ACC ]     STREAM     LISTENING       4371 2764/lpd Waiting    /var/run/lprng  

●オマケ2:VMwareが「2GB以上のファイルサイズに対応してない」と文句を言う

KD22上に存在する、でっかいvmdkファイルを持つVMwareの仮想マシンを起動しようとすると、 以下のようなエラーが表示される。

テキスト検索する人のために、テキストも残しておこう。

VMware Player はこの VM に必要な仮想ディスクのうちの 1 つを開け  ませんでした。仮想ディスクのサイズがホスト ファイル システムでサポートさ  れている最大ファイル サイズを超えています。一部のリモート ファイル シス  テムは、サーバ上のファイル システムではサポートされていても 2 GB より  大きいファイルをサポートしていません。    ファイルサイズが大き過ぎます    ディスク「D:VMwareUbuntu 64bitUbuntu 64bit.vmdk」、または  このディスクが依存するスナップショット ディスクを開くことができません。    モジュール DiskEarly のパワーオンが失敗しました。    仮想マシンの起動に失敗しました。  

多分、KD22のsambaが古いとか設定が悪いからだと思うが、どうしようもない。 VMware側、仮想マシンの.vmxファイルに一行追加することで回避可能なことが わかったので、ここではそれをご紹介。

diskLib.sparseMaxFileSizeCheck= "false"  

なんで直るのかはよくわからない。設定するパラメータ名からは、「Sparseファイルの 最大サイズをチェックしないようにする」ようだが…なんでHDL2-Aでは こんなパラメータ無しに動くんだか。Shuttle EUに(英語で)報告だけはしといたので、 そのうち直ってくれるかもしれない。HDL2-Aでは起こらないのも謎。

●オマケ3:RAID再構築にかかる時間

4TB HDDx2のRAID1の再構築にかかる時間は、13~14時間程度だった。長いよ! もちろん、RAID1なので、再構築中にもアクセスはできるから困らないけれど、 それにしても長いよねぇ…。言えば「RAID1の再構築」って、右と左のHDDの 内容全部コピーするってことだから、4TB/13時間=89.6MB/s でそのくらいかかるのは わかるけどねぇ…。

●オマケ4:HDDの温度

WebUIの管理ツールからsmart情報が見れるのだが、 後方ファンの運転を「自動」にしておくと、 ほとんどアクセスしてなくてもコンスタントに50℃を超える(室温28℃時)。 後方ファンは常にOnにしておいたほうがいいと思う。 しかし、Onにしといても、同じ条件で40℃までしか下がらない…。

吸気口は正面から見て右側下部にスリットとして用意されているが、ホコリで 目詰まりしそうだ。

●オマケ5:使われてるファンの種類

分解した時に確認した。APISTEKのMODEL SA7202L(DC12V 0.15A)だった。 70x70x15mmのフツーのファン。 KD20のファンとは違うんだな…。 でも配線は、刺さってるのをケース側面から見て左から赤・黒・青で、 フツーのファンと同じ模様。 KD20の変態ファン配線とはちょい違うみたい。なんでやのん。

●オマケ6:ファームウェアの複号化

頒布されているファームウェアはopensslで暗号化されているので、 パスワードがわかれば以下のコマンドで複号化でき、 元のファイル名どおりtar+gz形式となる。パスワードがわかればな!

# openssl enc -des3 -d -a -k <パスワード> -in <元ファイル> -out <複号済ファイル>  

なんで気づいたかというと、base64で一段階デコードできて、先頭に”Salt__”という 文字列が見えたから。あー、ソレはopensslで暗号化したデータですわー、という ところ。あとはごそごそ解析したら分かったというかそんな。

●オマケ7:sshdを有効にできるか?

結論:できる。ちょい難しいしトリッキーだけど。

rootfs.ubiをごそごそしてたら、/bin/sshdなんてのを発見。あまつさえ、 /etc/rc.d/sshd.shなんてのもあるし。これはもう神が有効にせよとゆってるに 相違ない!ということで有効にする方法ないかなー、と調べてみる。 カッコいい方法がこちらにあるのだが、 残念ながら現在のファームウェアでは既に対策済み(セキュリティホールだし)のため、 この方法は使用できない。

色々やってみて、我輩はKD22上でsshdを有効化できた。rootでlogin可能。 上で紹介したdmesgはそれで取得したもの。方法は以下の通り。 KD2xで共通して使えるはず。

  1. ファームウェアを入手
  2. ファームウェアを展開して、rootのパスワードを変更
    ※我輩はパスワードを変更するスクリプトをファームウェアに入れ込んだ
  3. そのファームウェアでKD22をupgrade
  4. http://KD22のIPADDR/admin/ssh.php(root/backdoor)にアクセスしてsshdを有効化

ファームウェアの展開方法は、本ページ上の情報のみを駆使すればできるので、 興味ある人は色々調査してみよう。 当然自己責任なので、キミが色々考えて実行した結果KD22が動かなくなったとしても 我輩は知らんよ、とあらかじめゆっておくよ!

2014/11/23追記。別のホールを使った ハックが発表された。結局、どうにかして一度rootのpasswordを設定しなきゃ いけないというアレはあるけれど、http://IPADDR/admin/ssh.php をちゃんと使って いるのは偉い。我輩、このphpスクリプトの存在は知ってたんだけど、 IDはわかった(=root)がパスワード(決めうち)がわかんなくて使ってなかった。 ら、root/backdoorって!ちょっと安直すぎやしないかShuttleの中の人。 コメント読むと作ってるのは中国人らしいので、まぁそんなもんかなという気は しないでもないけれど。グローバルに展開されるphpスクリプトのコメントが 中国語というのもスゴいものがありますなぁ。

USBシリアルを繋いでシリアルコンソールを使えるようにした人も居るねぇ… ハックして遊べる機械は楽しいよね!

■マメ知識

  • バックアップやコピー、領域の拡大方法はLinuxのものがそのまま使え、 つまりHDL2-Aの方法もそのまま使える。

■おわりに

「全部自己責任」という原則において、皆様からの質問には基本答えない。 でも、ご意見や情報、誤情報訂正要求(根拠つき)などは募集中。 掲示板経由でも メール経由でも構わないのでどうぞ。