cles::blog

シスコから「Employees Want Mobility & Flexibility - Is I.T. Ready? - Cisco News」という調査が公表されています。

ネットワーク機器の会社としてリモートアクセスを推進しているシスコのレポートであることを差し引いても国ごとの差を見ていると結構面白いです。明らかにロシア、インド、中国の回答傾向が違うのが分かります。実際にリモート勤務ができるかといえば、開発職であれば比較的容易だと思いますが、営業とかだと難しいかもしれません。個人的にはガリガリ開発する場合は家でやったほうが効率が高いですが、ミーティングはテレカンよりも実際に会って話すのが好みです。

【Cisco調査】「オフィスにいなくても生産的な業務はできる」と考える従業員が60％ : 企業クライアント戦略 - Computerworld.jp

調査によると、「生産的かつ効果的であるためにはオフィスにいる必要はない」とした回答者は調査国全体で60％。国別の集計では、インドでは93％もの回答者が「オフィスにいる必要はない」と考えており、中国（81％）やブラジル（76％）でもそうした志向が強く見られた。ちなみに、日本では44％が「オフィスにいる必要はない」と回答しているが、これは調査国中でドイツ（43％）に次ぐ低い数値であった。

先日からRubyのスレッドの挙動に振り回されている^*1わけですが、これまでに試したのはmingw32版のv1.8.7とv1.9.2だけでした。結論としては、これらの実装からマルチスレッドでWin32OLEオブジェクトの呼び出しを行うと、プロセス全体がブロックしてしまうようです。

それではJavaで実装されているJRuby や、.NET Frameworkで実装されている IronRuby の実装はどうなっているのだろうという疑問が湧いたので、今日はこれらの実装で先日のプログラムを流して、これらがどのような挙動を示すのかについて調べてみました。結論から述べると、これらの実装はWin32OLEのようなネイティブのライブラリを呼び出しても、他のスレッドがブロックすることはありませんでした。本家版のRubyと、JRubyやIronRubyは厳密にはスレッドの挙動が異なっているようです。

• ^*1: 「Ruby 1.8 と 1.9 のスレッドの違いにハマる」や「RubyのWin32OLEは現状でマルチスレッド対応ではないらしい」を参照のこと。

今日から発売になった、ペプシモンブランを早速買ってきてみました。

「ペプシモンブラン」季節限定発売　2010.9.21　ニュースリリース　サントリー

今回は、栗を使った人気デザート「モンブラン」をテーマにした「ペプシモンブラン」を発売します。「ペプシモンブラン」は、「モンブラン」のような甘い味わいと香りが特長のコーラ飲料です。パッケージには、フランス語で“白い山”を意味するモンブランを表現するために、雪が降り積もった栗の実のイメージをデザインしました。

キワモノ系のペプシはこれまでにアイスキューカンバーとか、しそとか、バオバブとか、あずきなんかがあったわけですが、これらは売っているうちは何本か飲んでいました。しかしながら、今回はこれはもう買わないなと初めて思いました。ちょっと甘すぎです。

先日、「ソースから最新版をインストールすると、アンインストールできないので管理が面倒ですよね」という話をしていたら、「paco とか使えばいいのに」と言われたのを思い出したのでインストールしてみました。これを使えばyumやaptでインストールしたものでなくても、インストールしたプロダクトを管理したり、綺麗にアンインストールすることができます。特にRHEL系のディストリビューション（CentOSなど）では事情があって最新版が欲しい場合にはソースから入れるしかないことが多いので活躍する機会も多そうです。

ちなみにどうやってこのソフトウェアが動作するかという種明かしについては、 paco のプロジェクトのウェブに下記のような記載があります。

paco - a source code pacKAGE oRGANIZER for Unix/Linux

How does it perform this magic? It is accomplished using the LD_PRELOAD method, which preloads a shared library before installation using the environment variable LD_PRELOAD. During installation, this library catches the system calls that cause filesystem alterations (such as open, link, rename, ...), and logs the created files.

LD_PRELOADを使っているようなので、おそらくファイル書き込みをすべてフックして記録しておくのでしょう。
分かってしまえば簡単ですが、ちょっと目から鱗が落ちました。

以下、インストールメモ。

障害でsendmailのキューにメールが溜まってしまっていたので、障害を取り除いて再処理をかけようと思ったら、コマンドが分からなくて難儀しました^*1。ググってみると「MTAの基本操作」に各MTAごとのコマンドがまとめてあったので、このURLをメモっておくと良さそうです。

• ^*1: 普段はqmailしか使っていないので、sendmailのやり方は分からないのです。。。。

朝っぱら^*1に自分のケータイがしつこく鳴るので眠い目をこすりながら確かめてみると、サーバが落ちてるよメールでした。とりあえずアラートを止めようとPC立ち上げたら、目が冴えてきたので、ついでにさくらに電話して状況を確認してもらうと、７月末に引き続きrejecting I/O to offline deviceが出るというパターンでした。

いい加減プライベートなサーバのトラブルで睡眠を妨害させられるのにイライラしてきたので、本気でVPSへの移行を考えたいと思いますが、その前にできるだけのことはやってみようということでRAIDカードのドライバをアップデートしてみました。いちおう書いておきますが、トラブルもないのにRAIDカードのドライバをアップデートすることはお勧めできません。特にホスティングだとブートしなくなった場合の選択肢も少ないので、安易に真似しないでください。

以下、作業メモ。

• ^*1: 正確には2:45くらいだったので、寝たばかりでした。

以前に行ったESXi の SSH公開鍵認証ですが、リブートしたらログインできなくなってしまいました。

仕方がないのでパスワード認証でログインしてマシンを確認してみると/.sshディレクトリがなくなっていまいた。どうやらESXiコンソールの部分は起動するごとにイメージが展開されるような感じになっているようで、自前のファイルを置いてもイメージに保存してやらないと、リブートする度にファイルが消えてしまうようです。リブートするごとに設定をしなおすのも面倒なので、なんとかならないかなと思って以前設定の参考にしたサイトを改めて読み返してみると設定の保存方法がちゃんと記載されていました。

Enabling SSH with public key authentication on VMWare ESXi 4 — Lucid Solutions

Save the SSH configuration
The most common way I have seen to save the SSH configuration is to use the '/bootbank/oem.tgz' archive. This file seems to be used for oem support on this IBM machine, so I didn't want to get in the way of this. So I have gone for an alternative scheme.

Add a new '/bootbank/home.tgz' archive with the contents of all home directories (both the root users home directory, and users home directories).

# tar -C / -czf "/bootbank/home.tgz" /.ssh /home

Edit the '/bootbank/boot.cfg' file and add "--- home.tgz" to the end of the modules parameter:

# cat boot.cfg kernel=vmkboot.gz kernelopt= modules=vmk.gz --- sys.vgz --- cim.vgz --- oem.tgz --- license.tgz --- mod.tgz --- home.tgz build=4.0.0-208167 updated=1 bootstate=0

これに従って、home.tgzを作成し、/bootbank/boot.cfgを編集しておきました。
この方法ならば、oem.tgzを変更するよりも余計なことをしてしまう可能性が低いので楽でよいです。

ちょっとパケットキャプチャをして内容を確認してみたいことがあったので、WindowsだったらEtherealかなと思ってダウンロードしようと思ったら、いつの間にかWiresharkという名前に変更されていました。

「EtherealからWiresharkへの名称変更の経緯 - SourceForge.JP Magazine : オープンソースの話題満載」によると開発者の移籍時に商標の問題が発生して変更されたようですね。変更されたのは2006年の話らしいのですが、このところ出番がなかったので気づいていませんでした。昔はHTTPのヘッダを見るのによく使っていましたが、最近はFirebugで済ませられるようになりましたからね。

Wireshark プロジェクト日本語トップページ - SourceForge.JP

Wiresharkプロジェクトは、ネットワークプロトコルアナライザWiresharkを開発するプロジェクトです。SourceForge.JPのWiresharkプロジェクトでは、SourceForge.netのWiresharkプロジェクトの日本語ミラーを行っています。WiresharkはUNIX/LinuxやMac OS X、Windowsで動作するネットワークプロトコルアナライザです。コンピュータがネットワークを介して通信するパケットを収集し、その内容や送信先などを解析することができます。

ドライバのインストールとか使い方については以前と大差ない感じです。

研究中のプログラムからtaskkillを使ってプロセスを終了する処理を書くように後輩に指示をしておいたら「XP Homeにはtaskkillがないんですよ。XP Homeは無視しますか？」と言われてしまいました。普段、WindowsはProfessional/Business以上のエディションしか使っていないので、taskkillコマンドが同梱されていないことをまったく想定していませんでした。流石にそれはまずいということで、ワークアラウンドとして何かフリーで使えるタスク終了用のユーティリティがないかなと思って調べてみたら、下記のtaskkill簡易版(taskkill0.exe)が使えそうだったのでメモ。

taskkill簡易版の詳細情報 : Vector ソフトを探す！

Windows XP Professional等に付属しているtaskkillコマンドと同等の機能をXP Home Editionでも使用するためのコマンドです。 ただし、使用できるオプションは/F /IM /PIDのみとなります。

内容は単純なC#のプログラムなので、ちょっとした拡張をするのも簡単そうです。
ライセンスもGPLなので、配布に制限がないのもいいですね。

研究のためにcmd.exeのログを取りたいという話になったので、ちょっと調べてみたら下記のエントリで紹介されている方法が使えそうだったのでメモ。

・コンソール(CMD.EXE)のログを取る(不完全版)
・コマンドプロンプトのログを取る (その2)

仕組み自体は、CreateProcessで標準入出力をリダイレクトしたCMD.EXEのプロセスを作って、匿名パイプで出力を取得してファイルと画面に出力する、という至って普通のやり方です。

回収の手間と正確性を考えると本当はネットワーク上のサーバーに結果を送出するようにしたいところですが・・・・・良く考えたらそんなもの作ったら普通にウィルスなので、研究目的とはいえ今回は実装を見送ることにしました。こういう系のツールは証跡管理ソリューションとか調べたらなにかあったりするのかな。