メランジ雑記帳

iPhone4の感想

admin — Sat, 04 Sep 2010 21:51:41 +0000

仕事の関係でipod/touchを使っていたのであるが、友人の間で電子書籍関係の話題が盛んになっているので、好奇心からついに携帯電話から移行した。
通話時のマイクの性能はかなりいいし、音もいいような気がする。いままで利用していた携帯電話であると、聞きにくい場合は（これは角度が問題なのであるが）、顔を押し付けるようにしてその結果、電話が切れていたことがかなりあった。また音質もあまりよくないわりに料金が高いので、有線電話が可能な場合はそれを利用することにしていた。というわけで、NTTのISDNの黒電話をまだ使っている。もう２０年近くになるが、使えているし、音質は一番いい。
話が脱線したが、iPhone4はこれまでのiPodよりも、（音楽の）音質がいいように思う。それと別にiPhone3時代から利用しているTさんがいろいろと電子文庫を見せてくれたので、自分も調べてみた。青空文庫という（著作権がきれた）フリーの電子書籍を扱っている組織があり、かなりの古典があった。XHTMLになっているので、ある程度はフォーマッターを通せばタイプセッターした形になりそうであって、実際、豊平文庫というアプリをダウンロードして使ってみると、縦表示の読みやすい文章であった。

上記の写真はNIKONの軽量タイプのものであるが指紋がとれているところが、ページを２２０ページほど捲って夢中になった様子を示している。
iPhone内蔵のスクリーンショット機能（スリープ＋ホーム）でとったものをFedoraのUSBにiPhoneを接続してBLOG用のサーバにアップロードしたものが以下の写真である（627X739ピクセルとなっている）。USBで接続すると、Fedora(12)はiPhoneという名前でマウントしてデスクトップに自動的に表示してくれる。DCIMというフォルダー（DigitalCamera IMagesの略）に写真がある（これはニコンと同じ）。

また、Appleの電子書籍アプリ『iBooks』（無料）というものもある。しかしこれはPDFを扱うようになっているもの。
また、以前にiPod/Touchの場合に別途購入が必要であったサーバ機能は、iTunesとIPhone OS 4.0の組み合わせでファイル共有が標準でサポートされたためUSBでMacやPCのiTunesを利用する人には必要がなくなった。

Failed shutdown of Apache Portable Runtimeへの対処

admin — Sat, 28 Aug 2010 00:55:00 +0000

tomcatをシャットダウンしても、上記のエラーになっていると、スレッドがとまらないし、大体tomcatプロセスが生きたままになってる。
WEBでサーチしたら、${tomcat}/conf/server.xmlの以下の

部分をコメントアウトすべしというものを発見した。JMXを使ってJAVAシステムのメモリー等の使用量の変動を調べたこともあるが、安定するとあまり使わなくなったので、コメントアウトすることに決定。

上記のエラーはでなくなったし、プロセスもめでたく成仏した。
スレッドはdestroy()メソッドを用意してinterruptをかけて、そこでcatchして、returnすることにより消滅させた。

このような工夫をしないと、周期的に動作しているスレッドが、その他のオブジェクトは破壊されて消滅しているのにそれを利用しようとしてnull pointe exceptionを多発してしまう。

.forwardファイルのパーミッション

admin — Fri, 13 Aug 2010 22:38:00 +0000

.forwardに

other@company.co.jp
\trueme@company.co.jp

というような内容を書いておくと、自分あて（trueme@company.co.jp)に来たメールを保存し、かつ別のアカウントにメールを送ることができるのだが、

/var/logs/maillogを読んでいると、

Aug 14 07:20:05 MailHost sendmail[17480]: o7DMK113017476: forward /home/trueme/.forward: Group writable file

というようなエラーが出力されていた。.forwardは個人の設定ファイルであるので、グループで書き込み可能というのはやはりまずい。

chmod g-w .forward

で解決した(転送できるようになった）。

（grubで）ブートしている時になにをしているのか見たい場合には？

admin — Thu, 12 Aug 2010 20:05:33 +0000

fedora 8あたりからであろうか、ブート時の処理が白と青のストライプで進行状態だけのシンプルな表示になってしまって、まるでWIndows風だ、と思った。
この時、何をしているのかを知りたい場合に、私は、F2を押している。
すると大体は

/dev/sdなんとか： |=========== 28.3%

などの表示をしているところからfsckが走っていることが分かる。
このfsckは２０回のリブートごとに起きるようだ。

Fedora 12 から Fedora にpreupgradeでアップグレードする

admin — Mon, 09 Aug 2010 07:54:22 +0000

/bootがかなり大きいので、オンラインでFedoraをアップグレードした。
16:50あたりから始めてどうなることか。
以下がその時の様子である。

16:55あたり

17:07分あたり

17:08あたり

ここでリブートを選択した。

17:12あたり
データボリュームとインストールボリュームを選択する。

17:15 依存性のチェック
これは意外に早いが…

17:17 Preparing transcation from installation source 1841個
18:03 この時点で1313/1841であった。
19:30あたりで終了したようだ。ログイン可能になっている。

やはりアップグレードはクリアインストールに比べて時間がかかるがデータなどが大体はそのまま使えるのでしかたがないか。
ということで64ビット版もFedora 13になった。苦労しなくてできたのでうれしい。
DBはきちんとバックアップもとったし…めでたしめでたし。
しかし、外人のBさんのXPを土曜日にアップグレードしたときには、Ventura Publisher 8の関係でSystem7 にはできなかった。

HDDのMBRを調べる

admin — Mon, 09 Aug 2010 07:27:02 +0000

これはWikipediaのMBRの記事（http://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%96%E3%83%BC%E3%83%88%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89）を検証してみた記録です。

まず、ハードディスクの第一セクター（たぶん習慣として０からではないとおもったが）だけをとりだす。
（ルートで実行）
$ su
# dd if=/dev/sda of=firstsector_of_hdd.bin count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 4.6112e-05 s, 11.1 MB/s
# chown ユーザの名前 firstsector_of_hdd.bin
# exit
$
で通常ユーザに戻る。

$ xxd firstsector_of_hdd.bin 0000000: eb48 9010 8ed0 bc00 b0b8 0000 8ed8 8ec0 .H.............. 0000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600 ...|.........!.. 0000020: 00be be07 3804 750b 83c6 1081 fefe 0775 ....8.u........u 0000030: f3eb 16b4 02b0 01bb 007c b280 8a74 0302 .........|...t.. 0000040: 8000 0080 3f8b 0400 0008 fa90 90f6 c280 ....?........... 0000050: 7502 b280 ea59 7c00 0031 c08e d88e d0bc u....Y|..1...... 0000060: 0020 fba0 407c 3cff 7402 88c2 52f6 c280 . ..@|<.t...R... 0000070: 7454 b441 bbaa 55cd 135a 5272 4981 fb55 tT.A..U..ZRrI..U 0000080: aa75 43a0 417c 84c0 7505 83e1 0174 3766 .uC.A|..u....t7f 0000090: 8b4c 10be 057c c644 ff01 668b 1e44 7cc7 .L...|.D..f..D|. 00000a0: 0410 00c7 4402 0100 6689 5c08 c744 0600 ....D...f.\..D.. 00000b0: 7066 31c0 8944 0466 8944 0cb4 42cd 1372 pf1..D.f.D..B..r 00000c0: 05bb 0070 eb7d b408 cd13 730a f6c2 800f ...p.}....s..... 00000d0: 84f0 00e9 8d00 be05 7cc6 44ff 0066 31c0 ........|.D..f1. 00000e0: 88f0 4066 8944 0431 d288 cac1 e202 88e8 ..@f.D.1........ 00000f0: 88f4 4089 4408 31c0 88d0 c0e8 0266 8904 ..@.D.1......f.. 0000100: 66a1 447c 6631 d266 f734 8854 0a66 31d2 f.D|f1.f.4.T.f1. 0000110: 66f7 7404 8854 0b89 440c 3b44 087d 3c8a f.t..T..D.;D.}<. 0000120: 540d c0e2 068a 4c0a fec1 08d1 8a6c 0c5a T.....L......l.Z 0000130: 8a74 0bbb 0070 8ec3 31db b801 02cd 1372 .t...p..1......r 0000140: 2a8c c38e 0648 7c60 1eb9 0001 8edb 31f6 *....H|`......1. 0000150: 31ff fcf3 a51f 61ff 2642 7cbe 7f7d e840 1.....a.&B|..}.@ 0000160: 00eb 0ebe 847d e838 00eb 06be 8e7d e830 .....}.8.....}.0 0000170: 00be 937d e82a 00eb fe47 5255 4220 0047 ...}.*...GRUB .G 0000180: 656f 6d00 4861 7264 2044 6973 6b00 5265 eom.Hard Disk.Re 0000190: 6164 0020 4572 726f 7200 bb01 00b4 0ecd ad. Error....... 00001a0: 10ac 3c00 75f4 c300 0000 0000 0000 0000 ..<.u........... 00001b0: 0000 0000 0000 0000 92db 0400 0000 8001 ................ 00001c0: 0100 837b 3b7f 3f00 0000 0040 1f00 007b ...{;.?....@...{ 00001d0: 3c7f 83fe ffff 3f40 1f00 0000 e6aa 00fe <.....?@........ 00001e0: ffff 82fe ffff 3f40 05ab 0227 a303 0000 ......?@...'.... 00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U. [hitoh@uq7 ~]$

最初の４４６バイト（５１２ー６４ー２：16進で01BEバイトまではOSによらないIBM＋マイクロソフトが作成した
ブートプログラムで、これがメモリにロードされる。
その内容は大体は基本パーティションでブート可能フラグの立っているものを探し、それをブートするという、
第一次ブート部分であるが、今回の場合にはLINUXのGRUBが入っているため、GRUBのものに置き換えられている。
最後の２バイトは55aaでこの値でなければMBRとしては扱われない。
のこりの446バイト目から６４バイトの部分は、

$ dd if=firstsector_of_hdd.bin of=partition_table.bin skip=446 bs=1 count=64
64+0 records in
64+0 records out
64 bytes (64 B) copied, 0.000605727 s, 106 kB/s

$ xxd partition_table.bin
0000000: 8001 0100 837b 3b7f 3f00 0000 0040 1f00  .....{;.?....@..
0000010: 007b 3c7f 83fe ffff 3f40 1f00 0000 e6aa  .{<.....?@......
0000020: 00fe ffff 82fe ffff 3f40 05ab 0227 a303  ........?@...'..
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
$

であるが、これは、

オフセット		内容	サイズ
Hex Dec
0×00	0	フラグ (0×80 = ブート可, 0×00 = ブート不可)	1
0×01	1	パーティションの最初のセクタ。CHS 方式での値。	3
0×04	4	パーティションの種類（パーティション識別子）。	1
0×05	5	パーティションの最後のセクタ。CHS 方式での値。	3
0×08	8	パーティションの最初のセクタ。LBA 方式での値。	4
0×0C	12	パーティションの全セクタ数	4

CHS関係のデータは以下のような並びになっている。
ヘッド
シリンダの上位2ビットとセクタ
シリンダの下位8ビット

UNIXのfdiskコマンドで検査すると

# fdisk /dev/sda

このディスクのシリンダ数は 182401 に設定されています。
間違いではないのですが、1024 を超えているため、以下の場合
に問題を生じうる事を確認しましょう:
1) ブート時に実行するソフトウェア (例. バージョンが古い LILO)
2) 別の OS のブートやパーティション作成ソフト
(例. DOS FDISK, OS/2 FDISK)

コマンド (m でヘルプ): p

ディスク /dev/sda: 1500.3 GB, 1500301910016 バイト
ヘッド 255, セクタ 63, シリンダ 182401
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
ディスク識別子: 0×0004db92

デバイスブート始点終点ブロック Id システム
/dev/sda1 * 1 128 1024000 83 Linux
パーティション 1 は、シリンダ境界で終わっていません。
/dev/sda2 128 178603 1433600000 83 Linux
/dev/sda3 178603 182401 30512001 82 Linux スワップ / Solaris

コマンド (m でヘルプ):

となる。

そこで、最初の１６バイトを分析すると、
8001 0100 837b 3b7f 3f00 0000 0040 1f00
である。

0バイト目 = 0×80でブート可となっている。
1バイト目 = 0×01でパーティションの開始領域のヘッド
2バイト目 = 0×01でシリンダの上位2ビットとセクタ
３バイト目 = 0×00でシリンダーの下位８ビット
この２バイト目がおもしろい。
xx xx xxxx
と考えると、最後の６ビットがセクターの番地をさしているようだが、0×00-0×3f(0-63)までしか表現できない。

ヘッド 255, セクタ 63, シリンダ 182401とあるので、どうも１番地から６３番地までを使っているようである。
ヘッドも0から始まるようである。

結局、最初のパーティションは、（論理セクターが０番目から始まるとして）

(C, H, S) = (0, 1, 1 )= 0 * 255 * 63 + 1 * 63 + (1 – 1) = 63-th sector
から
(C, H, S) = (0×7f, 0×7b, 0×3b) = 127 * 255 * 63 + 123 * 63 + ( 63 – 1) = 2,048,063-th sector
までの領域を使っていることになる。

差分をとると、2,048,000セクターつまり、１セクターは512バイトなので、1024Megaバイトを占めている。

これは、/bootにマウントされているパーティションである。
２番目のパーティションテーブルは、
007b 3c7f 83fe ffff 3f40 1f00 0000 e6aa
となっていて(C,H,S)ではもうオーバーフローしている。
LBA用の４バイトテーブルを使うことになるが、
最後のパーティションなどでは、最後の論理セクターがAEA86741になっている。これは1.5TバイトのHDDであるので、
LBAでも2.0Tでは論理的にあぶないかもしれない。

JBL４３４８スピーカーの前のナナオの液晶モニターを夏モードのためO君のモニタに

admin — Mon, 21 Jun 2010 10:33:21 +0000

このNANAOの液晶モニタは回転することができ、縦型にもできる。（先日場所を移動するときに思い出した！）
１２８０ｘ１０２４という今ではクラシックな解像度であるが、面白い。

縦にすると、A4縦のドキュメントが楽にみれるし、むかし、SonyのNEWSやMacintoshの文書処理マシーンをこのようにして使っていた（２０年前？）
その隣には、2560 x 1600 というモニター（DELLのキャンペーン価格のときのもので３年程度利用)があり、これはこれで強力。

ところで、これは（１２８０ｘ１０２４の縦型）、別の液晶でタッチパネル代わりになるモニターで組むシステムのプログラミングに使うモニターである。
C言語の委員をしていた人間がこういうことを行ってはいけないかもしれないが、マイクロソフトのいろいろな部品を作成するのにC言語を使ってきた経験があるが、
アルゴリズムっぽいところがあまりなくていろいろなAPIを組み合わせているだけの場合は、残念ながらVBが楽である。

であるから、あまり慣れてなくても、VBで遊べるようにならないといけない。

まあ、これはIEとの組み合わせ（Active X, COM , DCOM, .NET, OLEなど３年ごとに名前が変わったあれ）で簡単に利用できるようにとの仕掛けであってその理念自体には問題はない。（しかし、WEB SERVICEのような形を.NETが志向しているので、よい方向にいっている）。

突然話題がかわるのであるが、液晶をO君のM社製の古いモニターと交換したのであるが、本日「Duke Ellinton meets Coleman Hwakins」をCDでかけてみたら、音がいいのでびっくりした。スピーカーは秋葉原で７年前に購入したJBL4348。

部屋の音響の環境がよくなったのであろう。仕事のほうもすこし順調である。

WEBArenaの設定などをしてみた

admin — Mon, 21 Jun 2010 10:04:41 +0000

EC2のお客さんとは別にWEBARENAという日本のサービスを利用してみた。
感想は、CPUはそれなりに速い。回線も。ただし、メモリーが思いがけずにいっぱいになる。
（これはサービスをアップグレードしてもらえばOK）。このサービスではswap add やswap onが利用できないので残念。
でもこのサービスでこのレスポンスであればいいのではと思う。特にここはお客さんが以前から利用していた環境の移行であるので楽だった。

Y社のルータをVPNルータとして設定する

admin — Mon, 21 Jun 2010 09:55:08 +0000

Y社のルータをVPNルータとして設定するということを社内で実験した。大体OKであった。
先日はN社の無線LANの接続–>B社への切り替え–>新しいN社の無線ルータへの接続(８０２．１１n)を実施したばかりである。
以前はA社のルータを内部LAN側に入れて他社との一部サービス提供エリアへの接続にVPNを利用していた。

tracerouteの見方

admin — Tue, 08 Jun 2010 23:33:33 +0000

man tracerouteで調べると、面白い。
traceroute 相手のIPアドレス
というような使い方をするのだが、最初はTTL(Time to Live)を１にしたUPDパケットでかつありえないポート(33434-33500)を指定したものを送る。
すると、最初のルータはTTLが１なのでICMPパケットでTime Exceeded(時間を超過）というコードを返す。そのルータのIPアドレスが返る。時間を測定することもできる。１つだけではばらつきに左右されるので、３回送って結果を見る。
同様にTTLを２にしたいい加減なUDPを送ると、２番めのルータがやはりTime Exceededを返す。
TTLを３にすれば３番めのルータがTime Exceedを返す。
そして最後の終着点までHOPが達すると、Port Unreachableが返るはずである。
ただし、この過程で問題が起きると、以下のようなビックリマーク（Exclamation Mark)がついた文字が表示される。

After the trip time, some additional annotation can be printed: !H, !N,
or !P (host, network or protocol unreachable), !S (source route
failed), !F (fragmentation needed), !X (communication administratively
prohibited), !V (host precedence violation), !C (precedence cutoff in
effect), or ! (ICMP unreachable code ). If almost all the
probes result in some kind of unreachable, traceroute will give up and
exit.

たとえば、

$ traceroute 192.168.100.250 traceroute to 192.168.100.250 (192.168.100.250), 30 hops max, 60 byte packets 1 rtx1000.domain.jp (192.168.0.1) 1.015 ms 1.364 ms 1.933 ms 2 rtx1200.domain.jp (192.168.0.180) 4.112 ms 5.609 ms 7.243 ms 3 rtx1200.domain.jp (192.168.0.180) 4984.919 ms !H 4984.902 ms !H 4984.691 ms !H

となっているのは、３番目のところで、Host Unreachableということを検出したことを示す。
msが１行に３つ出力されているのは、３回のトライのTime Exceededが返るまでの時間を示す。
普通は５秒でタイムアウトする。その場合はmsの部分はアスタリスク(*)になる。
そういう場合にはそのルータのアドレスさえも分からない。つまり、最初の番号はTTLを意味している。
最後の行はルータがUDPを投げたが、５秒の間にICMPが返ってこなかったので、Host UnreachableというICMPを返したということだと思われる。存在しないIPに対してもこのようなことが起きる。

しかしながら、manによると、最近ではFirewallがありえないポートにたいしてフィルターで無視するようになっていることもあるのであまり使えないということ。
そこで、-M tcpとし、普通はOKの８０晩ポートを使うという方法が選択できる。（-Mはメソッドを意味する）

# traceroute -M tcp www.microsoft.com traceroute to www.microsoft.com (207.46.170.10), 30 hops max, 60 byte packets 1 buffalo.setup (192.168.1.1) 1.169 ms 1.267 ms 1.535 ms 2 116-65-198-1.rev.home.ne.jp (116.65.198.1) 8.646 ms 12.726 ms 13.698 ms 3 10.202.97.3 (10.202.97.3) 13.678 ms 13.947 ms 13.936 ms 4 172.25.106.157 (172.25.106.157) 47.464 ms 48.474 ms 48.461 ms 5 172.25.108.1 (172.25.108.1) 15.546 ms 16.512 ms 16.500 ms 6 124.211.14.13 (124.211.14.13) 26.474 ms 20.327 ms 20.284 ms 7 otejbb203.kddnet.ad.jp (118.155.197.1) 11.514 ms otejbb204.kddnet.ad.jp (118.155.197.2) 11.090 ms otejbb203.kddnet.ad.jp (118.155.197.1) 15.392 ms 8 pacbb001.kddnet.ad.jp (203.181.100.62) 119.852 ms pacbb001.kddnet.ad.jp (203.181.100.186) 119.112 ms pacbb001.kddnet.ad.jp (203.181.100.62) 120.143 ms 9 ix-pa8.kddnet.ad.jp (124.211.34.134) 136.536 ms ix-pa8.kddnet.ad.jp (124.211.34.126) 131.309 ms 130.383 ms 10 203.181.104.206 (203.181.104.206) 134.208 ms 134.188 ms 121.053 ms 11 209.240.198.195 (209.240.198.195) 134.340 ms 134.320 ms 132.929 ms 12 207.46.40.62 (207.46.40.62) 137.654 ms 138.236 ms 130.004 ms 13 207.46.40.135 (207.46.40.135) 137.627 ms 147.294 ms 136.478 ms 14 ten2-1.tuk-76c-1b.ntwk.msn.net (207.46.46.13) 137.826 ms 142.419 ms 138.701 ms 15 po16.tuk-65ns-mcs-1b.ntwk.msn.net (207.46.35.142) 151.409 ms 140.033 ms 140.208 ms 16 wwwtuk2vip.microsoft.com (207.46.170.10) 139.979 ms 139.656 ms 152.326 ms