ESXi上のVMの1つとして動かしているOpenfiler、インストールしたときは2.3だったのだけど、2.99にマイナーバージョンが上がっていたので、アップグレードしてみたら、案の定ハマった(w)のでエントリー。

まず、アップグレード

conaryというパッケージシステムを使っているのは知っていたので、それでアップグレードできるんだろうなぁと予想はついたのだけど、やり方はよくわからなかったので、とりあえずサポートフォーラムを覗いてみたら、まさにドンピシャリのポストを発見。

ポストされてる書き込みに書いてあるとおりにコマンドを、Openfilerが動いているサーバのコマンドラインから

[root@openfiler ~]# conary migrate group-openfileresa-appliance=openfileresa.rpath.org@esa:openfileresa-3.0 --interactivePreparing changeset request...

実行して、しばらく待つ。

Job 166 of 166:    Update  group-core (/openfiler.rpath.org@ofns:2/2.3-36-3[X,~!alternatives,~!bootstrap,~buildtests,~!cross,desktop,~!dietlibc,emacs,gcj,~glibc.tls,gnome,~grub.static,gtk,ipv6,~!kernel.debug,~!kernel.debugdata,~!kernel.numa,~!kernel.pae,~kernel.smp,krb,ldap,nptl,~!openssh.smartcard,~!openssh.static_libcrypto,pam,pcre,perl,~!pie,~proftpd.auth_pam,~proftpd.ifsession,~proftpd.ipv6,~proftpd.rewrite,~proftpd.tls,python,readline,sasl,~!selinux,~sqlite.threadsafe,ssl,tcl,tcpwrappers,tk is: x86(i486,i586,i686) x86_64] -> /openfileresa.rpath.org@esa:openfileresa-3.0/2.99.2-5-1)    Erase   group-openfiler=2.3-36-3[~kernel.smp,~proftpd.auth_pam,~proftpd.ifsession,~proftpd.ipv6,~proftpd.rewrite,~proftpd.tls,sasl]    Install group-openfileresa-appliance=2.99.2-5-1** The update will restart itself after job 16 and continue updatingMigrate erases all troves not referenced in the groups specified.continue with migrate? [y/N] 

待っていると「続けるか？」と聞かれるので、ココで"y"と入力する。

「Dropboxからの17500/UDPがウゼー」と言っているだけでは、片手落ちだと思ったので、LAN Syncを止める方法も、エントリーしておく。

CUI版のDropboxのインストールは、

• さくらVPSでDropbox - webネタ
  
• さくら VPS でも Dropbox を利用する - 脳無しの呟き《土鍋と麦酒と炬燵猫》
  

あたりを参考にすれば、問題なく出来るはず。（このエントリーの本題じゃないのでリンクだけ紹介。）

LAN Syncが有効だと...

同じネットワーク上の別サーバでtcpdumpを動かしてport17500へのパケットを観察しつつ、インストールしたDropboxを起動してみると・・・。

nexus01:~# tcpdump -i any -s 1600 port 17500tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on any, link-type LINUX_SLL (Linux cooked), capture size 1600 bytes19:22:56.441745 IP dc207.local.downtown.jp.17500 > 255.255.255.255.17500: UDP, length 12119:22:56.441773 IP dc207.local.downtown.jp.17500 > 172.16.0.255.17500: UDP, length 12119:23:04.451670 IP dc207.local.downtown.jp.17500 > 255.255.255.255.17500: UDP, length 12119:23:04.451694 IP dc207.local.downtown.jp.17500 > 172.16.0.255.17500: UDP, length 121

という感じで、10秒おきぐらいに、ブロードキャストに向かってパケットが飛んでくるので、LAN Syncはデフォルトで有効になっているのが判ると思う。
まぁ、起動後5分ぐらいでパケットの送出は30秒間隔になるみたいだけど、やっぱり数としては多いなぁ、というのが感想。

むか〜し、書いておいたPostfixとその周辺の設定に関するエントリーが、ずいぶんとアクセスがあるので、改めて現在の設定状態を書きだしてみる。

以前書いておいたSMTPサーバ関連の設定の覚え書きから、かなり内容が変わっているんで、新しく残しておきます。

[From 設定覚え書き：Postfix編 | Linux - Soukaku's HENA-CHOKO Blog]

このエントリー、日付てみると7年も前なのに、アクセスはなぜか一番多いんだよねぇ。不思議不思議。
まぁ、SMTPサーバなんて一度安定して動いてしまったら、余程の事ない限りは設定弄ることないんで、

postfix + amavisd-new + clamav + spamassassin

という基本的な構成は変わらずに、

postgreypostfix-policyd-spf-perldkim-filter

を組み合わせているのが、現状の構成。

以前、会社PCでは、Primo PDFというのを使っていて、

英語版しかない、といってもメチャクチャ細かい設定は必要ないので、「とりあえずPDFの出力ツールが欲しい」という用途なら、インストールしておいても損はないと思う。

[From PrimoPDFを試す | Windows - Soukaku's HENA-CHOKO Blog]

というようなエントリーも書いたことがあるんだけど、最近はPDF reDirectというツールを使ってる。有料のプロフェッショナル版もあるけど、フツーに使う分にはフリー版で十分。

このへんとかこのへんで、MacBook AirのSSDのパフォーマンス測定やってるのを見て、「そういえば、iSCSIってどの程度パフォーマンス出てるんだろう？」と気になったのでMac miniの内蔵HDDとTimeMachine用に使っているiSCSI HDDのパフォーマンスを測って見た。
測定に使ったのは、Disk Speed Test。

iSCSIについては、以前ちょこっと書いたとおりVMware ESXi上にインストールしたOpenFilerで組んだNAS上で動いているもの。

とりあえず、無事に完了したようです、Lionへのアップグレード。

よくよく考えたら、このところ全然クリーンインストールしてなくて、Jaguar → Tiger → Snow Leopard とすべて移行アシスタントで環境移行してきたものの上に、Lionをアップグレードインストールしたという、ある意味と〜ってもダーティーなシステムなんだと思うんだけどなー。今のところは問題なく動いているようです。
Office v.XのようなPower PCアプリは当然のように動かないのは最初からわかっていたのでいいのだけど、それ以外は目立って問題はなさそうなので、一安心。

気になっていた

おぉっと、あとLion移行に向けては、globalSAN iSCSIの対応状況次第だなぁ。

[From 獅子来たる | Mac - Soukaku's HENA-CHOKO Blog]

についても、問題なくTimeMachineでのバックアップ先として、iSCSIターゲットが見えていますしね。

半日ほど使った感じでは、「Snow Leopardから劇的に変わってないけど、マウスホイールでのスクロールが逆なのが、イマイチ慣れん。」というとこでしょうかね。たぶん、スクロールの設定はこのままにすると思うけど。
便利だなぁ、と思ったのは、Finderで並び順を「アプリケーション」にすると、作成したアプリ毎にグルーピングしてくれるとこ。そのうえ、アイコン表示だと、グルーピングされた中をCoverFlowでスクロール出来るのはとてもいいかもと思うなぁ。これ、Windowsでも欲しい。（ｗ

あと、アップデート直後に「アップデートして、ちょっと画面とか変わってるから」とだけ言って、細かいことを伝えてない状態のまま妻がMac使ってたんだけど、特に違和感とか感じずに使えている模様。

ほぼ予定通り、昨晩からOS X Lionが発売開始になりましたねぇ〜。
ネットのそこかしこでインストールの記録やらインストール後のソフトの動作報告なんかが流れていて、ドツボにハマるポイントなんかもだんだんと見えてきているので、自分はその辺を見極めてからLionへ移行しようかなぁ〜。

自分の使っているソフトの中では、Officeをどうするかが悩みどころ。
サポートの情報でも、「Office 2004 for Mac以前はLionで動作しません！」って出てるし。

あとは、Microsoft Officeもv.Xというかなり古いバージョンが入っているのだけど、ちゃんと動いていてくれるのでこれはとっても助かってる。利用頻度が高いわけではないので、新しいバージョンにする必要性が全くと言っていいほどなかったり。

[From Macで使っているソフトをリストアップしておいてみる | Mac - Soukaku's HENA-CHOKO Blog]

まぁ、「v.Xなんて何年前にリリースされたんだYO！」ってぐらいなので、Lionでは動かなくなって当然なんだろうけど、逆によく今まで使えていたよなぁというのも正直なところ。
当面は、OOoかLibreOfficeあたりで凌いで、どうしても必要になったらOffice for Mac 2011を買うって感じかなぁ。（手軽に買えるという点では、iWorkという選択肢もあるんだけどさ。）

いつのの頃からか、毎週日曜朝に実行されるログローテートで何故かログ（postfix）が切り替わらない、という現象が起きつづけていて、仕方なく日曜日になると、

/etc/init.d/rsyslog restart

と、手動での切り替えをしてたんだけど、やっぱりメンドクサイということで、ログローテートを実行するlogrotateというそのまんまの名前のパッケージの設定を見なおして、それが変な動きをしていないかチェック。

ここしばらく、内々では使い続けていたApache Traffic Serverですが、v3.0.0として、正式リリースされたようです。

14 June 2011 --FOREST HILL, MD--The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of nearly 150 Open Source projects and initiatives, today announced Apache Traffic Server v3.0.0.

[From The Apache Software Foundation Announces Apache Traffic Server v3.0.0 : The Apache Software Foundation Blog]

Debianのパッケージとしては、まだ2.1.8-unstableだし、パッケージになるまでもう少しかかりそうなので、ソースを拾ってきて独自にdebパッケージを作ってみた。

まずは、作業したいサーバの/usr/local/srcあたりに、v3.0.0のソースをダウンロード。

# cd /usr/local/src/# wget http://ftp.riken.jp/net/apache//trafficserver/trafficserver-3.0.0.tar.bz2--2011-06-17 22:18:59--  http://ftp.riken.jp/net/apache//trafficserver/trafficserver-3.0.0.tar.bz2ftp.riken.jp をDNSに問いあわせています... 134.160.38.1ftp.riken.jp|134.160.38.1|:80 に接続しています... 接続しました。HTTP による接続要求を送信しました、応答を待っています... 200 OK長さ: 2418416 (2.3M) [application/x-bzip2]`trafficserver-3.0.0.tar.bz2' に保存中100%[======================================================================================>] 2,418,416    337K/s 時間 7.0s    2011-06-17 22:19:06 (335 KB/s) - `trafficserver-3.0.0.tar.bz2' へ保存完了 [2418416/2418416]

使い始めて、1週間弱経過したわけですが。＞Apache Traffic Server
朧気ながら、Squidとの違いも見えてきたので、気がついたことをいくつかメモ的に、書きだしてみます。

少なくとも、体感的にはTraffic ServerのほうがSquidよりも心持ち速いかなぁ、という印象を受けています。
定量的な測定はしていないので、ほんとにどっちが速いのかはわかりませんが、多分マルチスレッド化されているか否か、という点での違いが大きそうです。

psコマンドでは、そのあたりが分かりにくいので、"pstree -Gc root"で取得したプロセスの状態を比較してみると一目瞭然。
squidは、

     ├─squid3───squid3─┬─diskd     │                 └─unlinkd

と、psの結果とほぼ同じになりますが、Traffic Serverのほうは、

     ├─traffic_cop───traffic_manager─┬─traffic_server─┬─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                ├─{traffic_server}     │                               │                └─{traffic_server}     │                               ├─{traffic_manage}     │                               ├─{traffic_manage}     │                               ├─{traffic_manage}     │                               ├─{traffic_manage}     │                               ├─{traffic_manage}     │                               ├─{traffic_manage}     │                               ├─{traffic_manage}     │                               └─{traffic_manage}

と細かいスレッドに分割されていることがわかります。
マルチスレッド化されていることで、マルチコア環境ではかなり威力を発揮するんじゃないかなぁ、という感じなのでテストしてみる価値がありそうです。