項目
/1)緒言/ 2)使用環境/3)スタートはｐowerEdgeと古gcc/3)ずっこけSolaris-gcc環境/4)謎の香りgcc32dbg(pthr)/5)たまにできないから困る/6)setup-gsiもなかなか/7)環境設定、またまた謎のドット /8)ホスト認証の問題/10) bladeでクライアント環境を構築/
11)poweredgeからbladeへ証明書発行/12)両者の連携は確認/13)失われたMdsCpu /14)やはりLinuxなのか・・・ /15)Linux同士の連携/16)怪我の功名？Solarisにgcc-3/17)キーワード一個で世界が変わる/18)謎のサードパーティツールSysinfo/19)混成OS環境の構築/20)まだ終わらないぞSysinfo/
/21)逆転満塁サヨナラ代打ホームラン！/22)ようやくお見せできます、sample.pl/23)結言/
本文中、(*)のついている部分は、その詳細を「烏合の衆コンピューティング ・外伝」に記しました。
上記記事のインストラクションに従ってGlobus Toolkit-2.4の導入、動作確認、簡単なグリッドコンピューティング環境の構築と、記事で提供されたサンプルプログラムの実行を行った。
対象OSには後に詳述するがSolarisとLinuxを採用した。Solaris同士、Linux同士、及び両者の混成環境の構築を試みたところ、Solarisの場合MDSにおいてCPUの情報が得られないという問題が生じた。
この問題を調査した結果、Globus ToolkitはSolarisへの導入に際しては、CPU情報の取得に限りMagniComp社のSysinfoというツールとの連携を前提としていることがわかった。
ただし、このSysinfoツールは、フリーウェアとして提供されていた旧バージョンにのみ対応するようである。実際にSolaris用のフリーパッケージ配布サイトから旧バージョンを得て、SolarisからもCPUに関する情報を引き出すことができた。
この過程において非常にたくさんの経験、発見、教訓を得た。例によってどんなささいなことでも誰かの役に立つかも知れないことを願ってできる限り報告する所存だが、今回は特に「トラブルシューティングのためのインターネット検索の重要性と難しさ」を大いに痛感した。
異なる機種、OS、及びgccバージョンを使用した。もっともgccのバージョンについては積極的に変化させたかったというわけではなく、これまで使っていた旧バージョンを使ってみてからアップデートしてみたというだけである。
また、ネットワーク環境はインターネットに公開していないLANで、日常で用いる無線LANとのブリッジのためのアクセスポイントをゲートウェイに指定している。
IPアドレスは固定で、プライベートアドレスだが、実際の値を公開しちゃうのはちょっとアレなので、本報告上での区別をつけるために仮の値を通しで用いさせていただく。
ホスト名: blade のちblade.noniko.com
検索ドメイン noniko.com
試した役割: 認証サーバ・クライアント・サンプルプログラムの実行・DNS
IPアドレス: 123.456.789.10（仮）CPU: UltraSPARC-IIe 500MHz
RAM:768MB
OS: Solaris 9
gcc:version 2.95及び3.3
補助ツール: Sysinfo-3.2.2（フリーウェア）、-5.0（現行の有償製品の試用版）
ホスト名: poweredge のちpoweredge.noniko.com
検索ドメイン noniko.com
試した役割: 認証サーバ・クライアント・DNS
IPアドレス: 123.456.789.11（仮）CPU: PentiumIII 450MHz
RAM:128MB（一時期384MBに増強されたが最近また抜かれた）
OS :Solaris 9（この前実験的にRed Hatなどを入れたりしたので、Intel版Solaris 9をまたインストールする。
さらに、Webminのモニターに用いたとき、デスクトップに導入したGnomeの調子がおかしいなおかしいなと思っていたらいきなりXに死なれたなどの経験にもとづいて、今回はCDEデスクトップ環境を用いた。）gcc.version 2.95及び3.2.1
ホスト名: noni2.noniko.com
検索ドメイン noniko.com
試した役割: 認証サーバ・クライアント・サンプルプログラムの実行・DNS
IPアドレス: 123.456.789.12（仮）CPU: Pentium IV 1.8GHz
RAM: 768MB
OS: Red Hat Linux 9
gcc:3.2.2
ホスト名 :ptiple.noniko.com
検索ドメイン: noniko,com
試した役割: クライアント
IPアドレス: 123.456.789.13（仮）CPU:Celeron 900MHz
RAM: 256MB
OS: Red Hat Linux 7.2
gcc:2.96
まず、poweredgeでGlobus Toolkit(以下GT）をgcc-2.95でビルドしてみた。
GPT、GTの9つのバンドル及びSimpleCAを全てソースからである。偉そうに言うが要するにバイナリないしIntel版わ。
最初にpoweredgeを選んだ理由は、無論ピュアに実験用マシンであり、失うものはなにもないからである。 記事でも、HDD容量と時間に余裕があったらぜひソースからやってみれとのお達しだ。HDD容量はともかく時間は腐るほどある。
バージョン2.95のgccは、OS付属のCompanion CDからパッケージインストールしたものだ。だからかなり安心して使えるが、ちょっと古いのが気になる。わたしがUNIXの勉強を始めたときはカブキモノ扱いされていたgcc3だが、今は既に3.2.2などが信頼を得ているようだ。
だが、わたしのようなヤツはgccをアップグレードするのにGT導入以前の問題としてすったもんだする恐れがある。
記事にはgcc-3.2.0「以外」と書いてある。ババ引いた場合は「アップグレードかダウングレードしてください」とも書いてある。一方Perlは5.005「以上」と書いてある。そこでまず現行の2.95で試してみることにした。
なお、事前にBind8DNSサーバを構築済みである。もちろんWebminでチョ〜簡単ヨ、ホーホホホホ。
まずはGPTのインストールである。
Solarisの場合、perlのConfig.pmという設定ファイルを、SunCC環境用からgcc環境用に書き換える必要があった。この書き換えの詳細はいろいろなサイトで公開してくださっているので、のに子風情があえて記す必要もないだろう。
また、zlibc-1.4以上を導入する必要があるかも知れない。「知れない」というのは、以下のような理由による。
最初、GPTのセットアップコマンド./build_gptをかましたら、
「gpt-2.2.10/suppoert/Compress-Zlib-1.16/zlib-1.1.4・・・でターゲットlibz.aのエラー」
という感じのメッセージが出た。
それで、まずzlibとかいうのが、いつだか確かbladeでも何かのインストールをするのに足りないとか言われたよなあとウスラボンヤリと思い出した。そこで http://www.sunfreeware.com からzlib-1.1.4のパッケージをダウンロードさせていただいて、インストールした。それでも同じエラーだ。それで、上のComfig.pmの書き換えを忘れていたのに気づき、修正したところ見事エラーはクリアできた。
そこで「わたしって結構やるじゃん」と思ってふと気がついたのは、zlibのパッケージをわたしは間違ってIntel版ではなくSparc版で取ってきていた、ということだ。
それをIntel版Sol9にpkgaddして、インストールできていたのだ。
確かに、/usr/local/libフォルダ中に、zlibとかlibzとか言うファイルがちゃんとできている。
でもこれは本当に機能しているんだろうか。それともインストールしたものはライブラリ集とかで、バイナリの実行ファイルとかがないので、どっちのバージョンでも特に問題はなかった、ということなのだろうか。とりあえず謎である。
ただ、GPTのビルドの最後に、「お使いのgccはちょっと古いようですね」という警告は、出た。
不安を含みながらいよいよGTの9つのバンドルのビルドに入る。
ビルドコマンドで指定するオプション「flavor」でかなり迷った。お手本には「gcc32dbg」などと書いてある。gccのバージョン3.2.xを思わせる表記法だ。でも今使っているのはgcc-2.95。「gcc29」とかに直さなければならないのか？と迷った。
結論はそんな修正は何をしても受け付けられない。素直にお手本の通りにしたら何のエラーもなくbuildが始まった。
もしかしてこの32は3.2ではなく32bitとかの意味なんだろうか？だいたい、flavorとは何なのか？ウェブで検索してみるとどれもGlobus関係のものばかりだ。ひとつわかったのは、SunCCのようなgcc以外のコンパイラを、もしぜえたくにも使える環境にあってそれを使おうというならば、gcc32dbgでなくvenderccdbgという指定になるらしいということだ。
だが詳細はいまだに謎である。
9つのバンドルのビルドには結構時間がかかった(*)。2時間くらいか。その間に一度だけ問題が発生した。Solaris固有の問題ではあるが結局はわたしのドジなのかも知れない。
gpt-buildでビルドしていると、途中で、あるファイルをuntarできない、というメッセージとともに止まった。
多くのtar.gzファイルはSolarisのtarでも問題ないのだが、たまにディレクトリの検査合計エラーとかいうのが出てダメなときがある。 きっとそれだろうと思った。
記事にはインストールにはGNU tarが必須とちゃんと書いてある。一方Solaris9にはGNU tarがなんと標準でついている。だからコンパニオンCDにはついてこなくて、わたしは「どーしてGNU
tarなくなったのヨ」と怒ったりしたアホである。
Solaris tarは/usr/bin/tar, GNU tarは/usr/sfw/bin/gtarである。ユーザglobusの設定ファイルを見たら、ホレコマンドサーチパスのリストに/usr/sfw/binが抜けてるじゃん。それでGNU
tarではないtarが実行されていたのだろうが、多くはそれですんじゃうから気づかなかったというわけだ・・・
修正した。とはいえ、プログラムがgtarをGNU tarと認識してくれるかどうかはわからない・・・
ま、どーせいつもgtar使ってるんだからいいや、ということで今回
$ mv /usr/bin/tar /usr/bin/tarbak
$ ln -s /usr/sfw/bin/gtar /usr/bin/tar
としてしまった。するとエラーは解決した。
その他、特にData Management バンドルのインストールのときに、かなり多量のWarningが発せられた。だがこれはLinuxのgcc-3.2.1というベリー標準な環境でも出たから問題ないのだろう。
Simple CAは自身に認証局を立てた。gpt-postinstallは記事の通りに設定した。自分で認証局を立てる場合、これは結構時間がかかった。後述するが、認証局を立てないクライアントの場合はすぐ終わる。
setup-gsiコマンドのパスは結構深いし{CA HASH}とかからんで複雑だが、globus権限でpost-installをしたときに、このように打ちなさいヨというメッセージが出る。ターミナルにコピペの機能があればそっからちょっともらってくれば簡単だ。
だがそのとき気をつけるべきことがある。 実行時には「-default」引数を忘れるな、と書いてある。これを忘れやすい。
本当に忘れたら本当に、setup-gsiのインストール作業自体は問題ないように見えたのだが、そのあとUser-certificationの発行で即エラーになった。
しかし、そのような凡ミスとはチョと違う、ヒヤリとさせられる瞬間もあった。setup-gsiコマンドをかますと、Perlのほうから、ファイルが見つからないといってくるのだ。
問題のファイルはSetup.pmというファイルだ。もすこし上の階層から表すと相対パスで.../Grid/GPT/Setup.pmみたいなものが求められてるらしい。それがPerlで設定したパスリストの中から探していってもないというのだ。
だがファイル検索してみると、/usr/local/gpt/lib/perl/Grid/GPT/Setup.pmというのがあった。
確かにこのパスはエラーメッセージ中に表示された、パスのリストの中にはない。
他には、gpt-2.2.10のソースフォルダ中にもあるのだが、これは生焼けファイルの可能性が高い。
さてどうするか。その@Incとかいうパス設定を書き換えるのか。どうやって？（前にPerlで家計簿とかやってたヤツがこれだ・・・）
う〜ん。考えたのは、探してくれるらしいパスの中にシンボリックリンクを貼ることだ。それらしい場所にする。
ln -s /usr/local/gpt/lib/perl/Grid /usr/local/globus/lib/perl/Grid
これで実行したら動いてくれた。Solarisだけでなく、Linuxでも同様だった。
個人環境の設定で、環境設定ファイルにこのように書けとのことだ。
GLOBUS_LOCATION=/usr/local/globus
export GLOBUS_LOCATION
. $GLOBUS_LOCATION/etc/globus-usr-env.sh
開けば一目瞭然であるが、globus-usr-env.shは、以後の操作に必要な実行ファイルやライブラリファイルのパス指定をするスクリプトである。
問題はこの「.」だ。なくてもコマンドになりそうな気がするが・・・
あってもエラーにはならない。そして以後の操作はうまく行った。
環境設定ファイルに書き込んでもいいし、今一時的にやりたいだけなら、このままターミナルに一行ずつ入れてリターンしてもいい。そのときはやはり「.」をつけてもエラーにならない。
そしてどちらの場合も、この「.」がないと、コマンドを下したときには特にエラーにはならないのだが、いざ
grid-proxy-init
などをやったときに、「ライブラリファイルが見つかりません、致命的エラー、強制終了」となる。
つまりこのスクリプトが実行されていないのだということは容易に想像がつくが、ドチテなんだろ。シェルに弱いのに子にはわからない〜。
まず、「証明書の発行」セクションである。
ユーザ認証。フルネームをきかれるので、Heppoko Nonikoと入力した。
すると/O=Grid/OU=GlobusTest/OU=simpleCA-poweredge/CN=Hepppoko Noniko/
というユーザ情報が与えられた。
Host certificate, Ldap certificateでは、
-host poweredge.noniko.comと入力したのだが、これがあとで問題になった。
Personal Gatekeeperを起動した状態でのglobus-job-runコマンドはちゃんと動作した。
MDSを使ったgrid-search-infoでも、システム情報がわらわらと得られた。ただし、CPUの情報が取得できない問題には、この時点では気づかなかった。
GridFTPを使ったファイル転送も成功した。
おお、やるじゃん！ということで、「環境のカスタマイズ」に行くことにした。/etc/inetd.conf, /etc/servicesを記事のとおりに修正し(*)、grid-mapfileの登録も行った。
inetdの再起動で、gatekeeperがroot権限で起動。だがここでホスト認証の問題が起こった。globus-job-runでジョブを実行させようとすると以下のエラーが。
GRAM Job submission failed because authentication failed: Expected target subject name="/CN=poweredge"Target returned subject name="/O=Grid/O=Globus/CN=poweredge.noniko.com" (error code 7)
要するにそのマシンからアクセスするにはホスト名は「poweredge」でなきゃいけないのにおまえの持ち込んだ通行手形は「poweredge.noniko.com」名義じゃねえのか、ということらしい。DNSを参照してくれないのだろうか？
/etc/hostsには次のように登録してある。
127.0.0.1 localhost
123.456.789.11 poweredge loghost
こいつを読んでいるのだろうか。これに書き足してみた。
123.456.789.11 poweredge.noniko.com
やはりダメだ。書き「足す」では、先に短い名前のほうが読まれてしまうのだろうか。書き直してしまった。
127.0.0.1 localhost
123.456.789.11 poweredge,noniko.com loghost
今度は本日の日付が表示された。なるほど、DNSでいくらドメイン指定などしても、認証局はあくまで/etc/hostsの内容しか信じないと言うことなのだろうか。ちょっとケチくない？まいっけど。
Grid FTPもroot権限で立ち上がり、ファイル転送もできた。
MDS Serverの起動スクリプトまではやらなかった。手動でも簡単だもん。
次にクライアントとして同じSolarisマシン、bladeを用いることにした。
Sparcマシンならばバイナリも出ているが、Simple CAにはバイナリがない。SunCCでコンパイルされたバイナリ環境に、gccでコンパイルしたSimple-CAを組み込むのはちょっと不安だった。そこでこれもgcc-2.95でソースから全部やった。
Simple-CAは今度はpoweredgeで認証局を立てたときに生成された
simple_ca_{CA HASH}_setup-0.12.tar.gz
というものを持ってこないといけない。
さて、poweredgeで使った9つのバンドル・ソースと、poweredgeの.globus/simpleCA内にある上記の発行物をbladeに持ってくる。
もーしかしたらクライアントバンドルだけでいいのかもしれないが、記事には全て揃ってこそ確実とある。それにどーせ時間をいちばん食うのはクライアントバンドルのビルドなのだ。四の五の言わずに全部やる。
9つのバンドルをビルドしたら、記事にあるとおりに -install-only オプション付きで発行物をビルドする。
最後にgpt-postinstall。すると今度はあっさり終わる。認証局を立てないからなのだな。
それからroot権限でgsi-setupを、やはり引数 -defaultを忘れないようにして行う。
さてbladeはpoweredgeに認証してもらうクライアントなので、ユーザ認証は行わない。
poweredgeの/export/home/noniko/.globus をフォルダごと、bladeの同じ場所にコピーするだけだ。
ホスト認証はちょとめんどくさくなる。blade上でrootに上がり、
#grid-cert-request -service host -host blade.noniko.com
するとbladeの/etc/grid-security/hostcert_request.pemができるので、これを認証局のあるpoweredgeのglobusに送ってやらなければならないのだ。bladeのglobusは、認証に関しては何もしない。
poweredgeのglobusは以後いろんなマシンの認証をしなければならないことになるから、hostcert_request.pemの名前のままでは誰のリクエストかわからなくなってしまうので、コピーの際はhostcert_request_poweredge.pemなどとリネームした。認証局のほうでサインするときにも
$grid-ca-sign -in hostcert_request_poweredge.pem -out hostcert_poweredge.pem
みたいに出してやって、poweredgeのrootがそれを取りに来て自分の/etc/grid-securityフォルダに本来の名前でコピーするようにした。
LDAP認証も同様にして行った。
$globus-job-run poweredge /bin/date
$globus-job-run blade /bin/date
のいずれのコマンドをどちらの機種からかましてもそれぞれの日付が得られた(*)。故意にやったわけではないが時間が1分だけずれているので、ちゃんと指定のマシンで仕事がされていることがわかる。
また、anonymousによるMDSへの問い合わせは、以下のコマンドでよいことがわかった。
$grid-info-search -x -h poweredge
$grid-info-search -x -h blade
これもいずれの機種からやってもそれぞれの情報が・・・CPUの情報だけが得られていないことを、この時点ではまだ気づいていない。
しかし、いよいよ最後の仕上げとしてサンプルプログラムsample.plを実行したところ、結果は次のようだった。
=SEARCH BEST HOST= [Hosts]
poweredge-> 00
blade-> 00
[Best Host]
poweredge(00)
つまり、poweredge, bladeいずれも変数$cpuPowerがゼロデータしか得られなかったのだ。で、結局リストの最初にあったpoweredgeがホストに選ばれた。そのあとのジョブ自体は成功しているようだが・・・
変数$cpuPowerが得られない原因は、いずれの機種でもMDSでobjectclass MdsCpuが取得できないことにあるとわかった。これはそれぞれの機種においてgrid-info-searchをやってみてわかったことである。
grid-info-search -x -hとやると、全てのobject Classを要求したことになる。出力の最初は、その一覧だ。
version: 2
#
# filter: (objectclass=*)
# requesting: ALL
#
# blade, local, grid
dn: Mds-Host-hn=poweredge,Mds-Vo-name=local,o=grid
objectClass: MdsComputer
objectClass: MdsComputerTotal
........
で、どこかに
objectClass: MdsCpu
objectClass: MdsCpuCache
objectClass: MdsCpuSmp
objectClass: MdsCpuTotal
objectClass: MdsCpuTotalFree
と現れるはずなのが出てこない。別の
objectClass: MdsFsTotal
objectClass: MdsHost
objectClass: MdsMemoryRamTotal
objectClass: MdsMemoryVmTotal
objectClass: MdsNet
........
みたいの、ばかりだ。
この問題をWebで調べてみることにした。だがどうやって？とりあえずキーワードを「MdsCpu」にして調べてみる。すると出てくるのは当たり前のように表示されたという例ばかりだ。そして対象OSは全部Linuxである。
ひとつだけ、英語のglobus-MLで「私のマシンではMdsCpuというobjectClassが表示されません」というのがあった。おおッ、と思ったが、このヒトのOSはLinuxである。そして自己レスのような形で「rootでMDS
Serverを起動すると表示されますが、userで起動すると表示されません。なにかのセキュリティーの問題なのでしょうか？」
それ以降のレスはなかった。
第一、こちらはMDS Serverは当然のようにrootで起動している。ちょと違うようだ。
だったらとにかくLinuxでやってみるしかない。自作マシンのに子2号ことnoni2のRed Hat Linux 9にGTを導入する。ただしホスト名、検索ドメイン名等確定するためにいちどLinuxから再セットアップした(*)。
なにせgcc純粋培養のLinuxだ。PerlのComfig.pmもいじる必要はない。
globus toolkitをソースからビルド・・・速い！
のに子2号。PentiumIV-1.8GHz。3GHzが標準らしいこの時代に、IAマニアにはハナで笑われそうだが、poweredgeのPentiumIII-450MHzではゲッゲロゲロゲーロゲーロゲゲゲと2時間以上かかったコンパイルが、ケケケッと30分もしないうちに終わってしまった。出張中のダンナに「なんかあかぼうつかいにくくてヤだ〜(*)」「だからでびあんにしろヨ」「でびあんむづかしそ〜」などと携帯メールを送っている間に終わってしまった。技術の進歩はめざましいものである。
gccのバージョンは3.2.1。禁断のバージョン3.2ではない。ビルド、認証、動作全く問題なし。noni2.noniko.comで取得した証明書はすんなりと認証された。MDSについては、MdsCpu等Cpuに関するobjectclassが全て取得された。
ではまずLinuxどうしで連携を行い、かのsample.plを動かしてみることにしよう。
そのためには、とにかくCPU情報が出るかどうか確かめるだけのために、gatekeeperなどもPersonalで立てていたnoni2を、認証サーバとして環境構築しなければならない。
/etc/xinetd.d/globus-gatekeeperファイルの作成(*),
/etc/servicesファイルの編集を行い、xinetdを再起動してgatekeeperがrootで起動するようにした。
続いてptipleのRHL7.2にGTを導入。なぜこれをRHL9にアップグレードしないかというとUNIX USER様に添付された9はDVDであり、ptipleにはDVDドライブがないからだ。最後にCDでいただいたのは8.0だがこれには禁断のgcc-3.2-7が入っている（別に文句を言っているわけではありません）。
7.2に入っているgccはやはり2.96とチョと古いが、問題なくビルドできた。ホスト名ptiple.noniko.comでnoni2から証明書を取得。
Linux同士、なのか赤帽同士、なのか、ユーザ認証のときに小さな問題が起こった。前述の通りユーザ認証に関しては、認証局を立てたnoni2の/home/noniko/.globusフォルダを、ptipleの/home/noniko/.globusに持ってくればよい。だがそのときにファイルのパーミッションが自動で変わってしまうようなのだ。
それに気づかず、grid-proxy-init・・・とやると、いきなりエラーだ。
userkey.pemファイルがinvalid permissionであるようなことを言われる。
noni2からもらってきた.globusフォルダの中を開けると、userkey.pemというファイルがあって、プロパティを見ると、あら全てのユーザに対して読み書きそろばんなんでもござれになっている。いつもことあるごとにchmod
777を乱発しパチスロ野郎の異名を取るわたしだが、今度はこんなファイルに自分で触った覚えはないぞ？・・・まあいい。正常に働いているサーバnoni2と比べると、こちらの同じファイルは400、つまり所有者nonikoは読むだけ、他のユーザはアクセス全不可という鉄のパーミッションだ。これにあわせてptipleにコピーされたファイルのパーミッションを変更する。今度はちゃんと機能した。
以後RHL同士の連携は問題なく成功(*)、sample.plを実行し、noni2とptipleの$cpuPowerを有限値で取得・比較することができた。
だがSolarisだからできないと結論していいのか？Solarisだからコンパイルやインストール作業に微妙な違いがあって、わたしがSolarisにそれをさせられないというだけではないのか？
たとえばgccのバージョンだ。初心者・のに子には、gccのバージョンによって何が違って何が同じなのかなどは区別がつかない。古い2.95でやって一件動いているように見えても・・・
まあ・・・問題解決の見込みはあまりないとは思われたが、確認のためpoweredge, bladeにそれぞれgcc-3.2.1(*),
3.3(*)を導入してビルドし直してみた。
bladeについてはSolaris9用のバイナリが得られたのでバイナリインストールも試してみた。さすがバイナリ、さっきのPenIVでの驚きが色あせるほどのチョッパヤでインストールされた。
いずれのケースも、 認証やジョブの実行には問題はなさそうだ。だがやはりCPU情報の問題は解決されなかった。そりゃそーだろうな。
だがこんな機会でもなければSolarisへのgcc-3導入はできなかっただろう。それはよいことだ。
コーヒー休憩。その間もこの問題に関してWeb検索を行う。出てくるのはほとんど英語のディスカッションだ。
残暑厳しき午後3時。きっと今日本でSolarisのMDSでCPUの情報が得られない問題で悩んでいるのは主婦のわたしひとりなんだろうなと思った（もちろん、問題なく使っているヒトはたくさんいるのだろう）。
だが最近神様がプッシュしてくださることがなにかと多い。今回も、ずっと「MdsCpu Solaris」なんて感じのキーワードで検索していたのを、ふと
「MDS Solaris CPU」
にしてみた。するとヒットした最初のページのURLを見て思わずコーヒーを吹き出しそうになった。
Globus: Frequently Asked Questions about MDS 2.1
... Q: Why does no CPU information appear in my GRIS running on Solaris? The
Solaris CPU information
provider uses SysInfo, a 3rd party product. For further details of SysInfo,
please see http://www.MagniComp.com/sysinfo
The sysinfo executable should be in the path when MDS is installed. ...
www.globus.org/mds/mds21/FAQ.html
ちょっと待てー！こりゃ実践を始めてからわたしがさんざん突っつき回してきた、globus.orgのFAQページじゃないか？
でも、URLを見てわかった。これはglobus toolkitのFAQではなく、MDSのFAQなのだ！
ちなみに、いったいglobusのトップページからどうやってこのページにリンクできるのだ？さっきいろいろやってみたけど、わからないぞ！
上のGoogle検索の結果ではMDS 2.1のFAQと書いてあるが、あとで探し直した結果
http://www.globus.org/mds/FAQ.html
では、MDS2.2のFAQページにアクセスできて、同じものが見られた。
どうやらやっぱりSolarisは特別らしい。Sysinfoというサードパーティツールを使えば、MDSのほうでそれに対応してくれるということなのだろうか？
だが不思議なモノである。検索キーワード一個で結果が全然変わってくる、有効なキーワードの追加によりそれが行われるのはよくあることだろう。だがキーワードの削減、それも最も大事なキーワードであるはずのobjectclass名「MdsCpu」をふと落としたために、むしろ金的を射当てるとは・・・やっぱり、「何かが降ってくる」というのは本当にあることなんだろうか。
そこに行ってみる。Sysinfoというツールは有償だが60日間のお試し版はダウンロードできるという。SolarisのSparc版もIintel版もあって、落ちてきたのはshファイル一個。実行すればインストーラが立ち上がる。ライセンスナンバーをきかれるところで黙って改行キーを押せばお試し版扱いになる。
果たして動くのかこのsysinfo。インストラクションの通りに
/opt/sysinfo/bin/sysinfo -show cpu
とやってみる。
このソフトウェアは60日間有効のデモ版です。ライセンスを手に入れるにはどーのこーの。あと60日使えます。
というようなメッセージのあと、「システム情報」みたいな見出しが出て、「cpuはUltraSPARC- IIe」という出力が出た。
なるほど。ちゃんと動くらしい。だがdocやmanをいろいろひっくり返してみたが、「CPUの空き」を問い合わせるコマンドオプションはわからなかった。CPUのスピードとかキャッシュサイズとか、FPUがあるかどうかとか結構細かい情報はあるのだが・・・ダイジョブなんだろーか？
とにかくやってみよう。さて、「globus-toolkitのインストール時に、sysinfoへのパスを通しておけ」という。ということは、globus-toolkitを再インストールしなければならないということだ。ということはpoweredgeでまたゲロゲロゲーロ（以下略）と長い時間かけてはいられない。バイナリインストールできるbladeを使うに限る。
globusの環境設定で、PATHに/opt/sysinfo/binを追加する。
自分自身を認証局に、インストールをやり直す。
MDSサーバを立ち上げて、grid-info-searchをかましてみる。やっぱり、出てこない。
うーん、まあ。とにかくGlobus ToolkitはそのままではSolarisからCPU情報だけ引き出せないことが明らかになった、とするか？それが結論か？だがまだやってないことがある。SolarisとLinuxの混合グリッド環境だ。これができなきゃやっぱり面白くない。
ゆうべ久しぶりに出張から戻った夫に、「のに子のウェブサイトにそれなりにアクセスがあるのも、のにがすったもんだしながらいつも一応何かカタチにしているのが評価されてるからこそだろう。なんだかうまくできませんでした、でもわたしなりに楽しかったし〜、なんていう負け犬レポートなら俺が許さない」
と言われたことも、ずしりと心にののしかかっている。
SolarisのCPU情報は得られないにしても、Solarisを認証局にして、ここからsample.plを実行し、Linuxどもを点呼してCPU情報を集め、仕事をさせる。こういう格好ならなんかカタチになりっぽいではないか。
ということで、赤帽認証局は本日をもって閉鎖。サーバだったnoni2から、一度toolkitを削除する。念のためもう一度GPTからビルドし直す。そうしてbladeで発行したSimple
CAソースをもらってきてビルド。ユーザ認証フォルダのコピー、ホスト・LDAP認証もやり直し。ptipleも同様。
ちなみに、これらのコンピュータではもう/etc/hostsもDNSもバカバカ互いが互いを登録しあってて、もう住民全員顔見知りのナントカ村みたいな状態になっているので、その辺の配慮はもういらない。
2台のLinuxマシンとbladeは別の部屋にある。そこでbladeのGnomeでターミナルをバカバカ立ち上げてnoni2とptipleにtelnetログインし(*)、それぞれglobus,
noniko,root権限でこれらの操作を行う。blade自身も含めて計9枚のウィンドウを使い分ける。確かに、便利だ。UNIX及びX Window Systemというものの便利さを、こんなのはきっとほんの微細な片鱗ではあるのだろうが、ひしひしと感じる。
作業は結構順調に行って、bladeからsample.plを実行し、場合によりnoni2とptipleのどちらかに仕事をさせることができた。
そろそろこのへんでレポートを書くことにした。そのために、例のSysinfoの情報を得るに至った検索過程などをもう一度確かめているうちに、他にもGTでSolarisでSysinfoというようなページにチラホラ行き当たる。無視するわけがない。
それらの情報によると、 Solaris上で、MDSで、CPUの情報を扱うスクリプトは、/usr/local/globus/libexec/grid-info-cpu-solarisというファイルだ。このスクリプトを開いてみると確かにここが司令塔だとわかった。すなわち
${GLOBUS_SH_SYSINFO} -class device -format report -type cpu | \
ちゃんとGTのほうで、Sysinfoを使うようになってるみたいだ。そしてこれ自体をターミナルから実行することもできるという。今の問題と直接の関連はなさそうだがやはりいろいろな研究の過程で、rootで実行してみている例がウェブサイトにあった。
やってみる。
#/usr/local/globus/libexec/grid-info-spu-solaris
ギョギョ。ターミナルに「このソフトウェアは60日間のお試し版で・・・」というメッセージが！そして、
dn:
objectclass: MdsCpu
objectclass: MdsCpuSmp
objectclass: MdsCpuTotal
objectclass: MdsCpuCache
objectclass: MdsCpuFree
objectclass: MdsCpuTotalFree
Mds-Cpu-Free-15minX100: 00
Mds-Cpu-Free-1minX100: 00
Mds-Cpu-Free-5minX100: 00
・・・・・
なるほど。それらの値を取得し、そういう書式で出すためのスクリプトなのだ。だがデータは全部ゼロだ。
そして、grid-info-searchでは、ゼロデータは最初からツラも出せないと、そういうわけだったのだな。
ちょっと待て。それならもっと言えば、sysinfoコマンドそのものを入れてみんと。
#sysinfo -class device -format report -type cpu
このソフトウェアは60日間のお試し版です。以下いろいろ。
#
黙って無を返しやがった・・・・
もしかしてコマンド間違ってねーか？たとえばこう打ったらどう答えて来る？
#sysinfo -class device -format report
ゾロゾロゾロとデバイスに関する情報がでてきた。中にはCPUに関する情報もある。だが他にもPCIバスやらRAMやらネットワークアダプタやら、モニタやらキーボードまで。
だが、とにかくCPUに関する情報は確実に入っている。スクリプト内のコマンドを書き換えちゃったら、これらの情報の中からCPUに関する部分だけを取り出してくれるとかいうことはないかな？
grid-info-cpu-solarisの中身を書き換えてみる（無論バックアップは取ったヨ！）
${GLOBUS_SH_SYSINFO} -class device -format report | \
スクリプトを実行してみる・・・・そういう作りにはなってないようだ。スクリプトは得られたデバイス情報を全部CPUのそれと取ったようだ。CPUの数が55だかあることになって、Sun Fireとかあの辺を使ってでもいるようなゴージャスな気分・・・じゃねーだろ！
おまけに、カテゴリの割り当てが全部ズレちって、Mds-Cpu-Total-Free-1minX100: Sun Mycrosystems とかなってる。
きっとこのスクリプトファイルを書き換えればこれらの情報の中からCPUに関するものだけを取り出すことができるんだろうね。たぶん来年くらいには・・・
CPU情報だけを引き出すための別のコマンドは、なかなか見つかりそうにない。
やはりSysinfoお試し版なのがいけないのか？最初に必ず出てくるお試し版宣言が災いしてる？これが出ないようにスクリプトなどを書き換え・・・るのはリバースエンジニアリングとかいうヤツじゃん。ダメダメ。できないだろうしたぶんのに子ごときには。
まあ、MDSのしくみについてここまで勉強したんだから、さすがにそろそろあきらめるか！
ちょっと待て。そもそも「MagniComp sysinfo」というものに関して、検索してないじゃん。
いままでずっと「MDS Solaris Sysinfo」のような検索キーワードで調べて来た。思い切って「MagniComp Sysinfo Solaris」にキーワードを変える。すると！
「MagniComp Sysinfoは昔フリーウェアだった」という情報が。
そして、「Solaris 2.5用のドッ古いSysinfoが http://www.sunfreeware.com で配られてるヨ」という情報が！
ついこの前gccとか持ってきていたお馴染みの場所にあったとは！
行ってみると、sparc-solaris2.5用パッケージ及びソースとして、「sysinfo-3.2.2」というのがあった。
このsunfreeware.comはさすがにいつもかなり混んでいてなかなかアクセスしづらい。おまけにNetscape系だとリンクをクリックしただけではダウンロードできないトラブルというのもときどきある。優勝目前の阪神のようにやきもきイライラするわたしに代わって久しぶりの休日に家にいる夫が自分のPCのInternet
Explorerでダウンロードしてくれた。
Solarisのバイナリ互換性はかなりいいという夫の話だ。bladeのSolaris 9に、まずダメもとでバイナリのパッケージインストールをしてみる。ダメだったら100万年かかってもソースからコンパイルしてやる（レポート間に合わねえって）
インストール前にこれまでのsysinfoをアンインストールする。root権限で
/opt/sysinfo/setup -uninstall
とやる。いくつかのファイルは除去できなかったらしい。結局/opt/sysinfoフォルダを手動で消す。
落ちてきたのはsysinfo-3.2.2.gzというグズ野郎だ。
gzip -d sysinfo-3.2.2.gz とやって、
pkdadd -d sysinfo-3.2.2
インストール先は /opt/USCsysi がデフォルトのようだ。まあいいでしょう。デフォルトのままにしておいて、
opt/sysinfoにシンボリックリンクを貼ればよい。何のエラーもなく、インストールはされたらしい。
さて起動するのかな。
#sysinfo -format report -class device -type cpu
/dev/kmemファイルが読めません
という。超旧世代用のパッケージに対して過大な期待はしてない。システムを探すと/dev/kmemは確かにあった。でもシンボリックリンクである。ファイルマネージャでプロパティを見ると、root以外読めないという設定になっている。
userkey.pemのパーミッション問題のおかげで、やたら777モード発動から卒業しようと決心したわたしだ。/devフォルダ内の多くのファイル（全部シンボリックリンクのようだ）は他のユーザには読めるという755仕様。
chmod 755 /dev/kmem
とやってみる。コマンド再挑戦。
すると、
「sysinfo: /dev/ksyms is not a 32-bit kernel namelist」とのメッセージ。そりゃ完全64ビット環境だもん・・・と思っていると。
device | name | cpu0 | | SUNW,Sun-Blade-100 | | cpu | CPU | 502 MHz SUNW,Ultra
SPARC-IIe | | -1 | 0xffffffff | -1 | -1 | -267985964
device | desc | cpu0 | | 502 MHz SUNW,UltraSPARC-IIe
device | desc | cpu0 | Clock Divisors | 0x00000001.0x00000002.0x00000006
device | desc | cpu0 | Manufacturer# | 23
・・・・・・
出たー！
初めて、「黙って無を返す」でもなく、「全部のデータがわらわら」でもなく、cpuだけのデータが表示された！
もしかして上記の情報はセキュリティ漏洩？それでも構わないわ！これでクラックされてコワされたら次はBlade 1000買ってやる（うそ）！
ちなみに、今一般ユーザで同じコマンドを試してみたら
/dev/memが読めません
と言われて終わった。rootでやってよかった。
そんなことには気づかなかったわたしはそれでは本番のgrid-info-searchはどうだ？と一般ユーザにもどっていきなり
$grid-info-search -x -h blade objectclass=MdsCpu
version: 2
#
# filter: objectclass=MdsCpu
# requesting: ALL
#
# blade, local, grid
dn: Mds-Host-hn=blade,Mds-Vo-name=local,o=grid
objectClass: MdsComputer
objectClass: MdsComputerTotal
objectClass: MdsCpu
objectClass: MdsCpuCache
objectClass: MdsCpuFree
objectClass: MdsCpuSmp
objectClass: MdsCpuTotal
objectClass: MdsCpuTotalFree
objectClass: MdsFsTotal
objectClass: MdsHost
・・・（中略）・・・
Mds-Cpu-Cache-l2kB: 256
Mds-Cpu-Free-15minX100: 075
Mds-Cpu-Free-1minX100: 084
Mds-Cpu-Free-5minX100: 076
Mds-Cpu-Smp-size: 1
Mds-Cpu-Total-Free-15minX100: 075
Mds-Cpu-Total-Free-1minX100: 084
Mds-Cpu-Total-Free-5minX100: 076
Mds-Cpu-Total-count: 1
・・・・・
出た！初めてそれもゼロデータでないCPUの情報が！
ちなみに、本タイトルの「代打」というのは、Solaris9に対してSolaris2.5用のパッケージ、という意味だ。いんだけどどーでも。
とすればあとはsample.plの @hosts に輝かしきbladeの名前を書き込むだけだ。ゴー！
結果は以下の通り。
=SEARCH BEST HOST=
[Hosts]
blade -> 084
ptiple -> 052
noni2 -> 031
[Best Host]
blade(084)
=EXECUTE=
[Command]
/usr/local/globus/bin/globus-job-submit blade -s /export/home/noniko/grid/date.sh
[ContactString]
https://blade.noniko.com:33009/2043/1063596462/
=CHECK STATUS
[Done ]
= GET OUTPUT=
[Command]
/usr/local/globus/bin/globus-job-get-output https://blade.noniko.com:33009/2043/1063596462/
[Output] blade
Mon Sep 15 12:27:47 JST 2003（阪神タイガースが優勝をキメた日だということがわかる。この時刻ではまだだけど）
うーんまあ。これが信用できる値かどうかはわからない。だって認証サーバだしプログラムの実行（かつファイル書き出し）をやってるbladeがいちばんヒマで、ただ立ち上げてせいぜいジョブが呼ばれるのを待ってるだけの赤帽どもがなんでそんなに忙しいのか？
だがちょうどそのとき赤帽どものいる部屋へ行った夫の話では、「あいつらなにやってんだろうね、HDDゲリゲリ言ってなんかキモ」らしいから、ちょうどそんな不明な自動処理をしている最中だったのかも知れない。
そういうわけで、SolarisとLinuxを含むグリッドコンピューティング環境の構築を試み、SolarisではそのままではCPU情報を引き出すことができないという問題になんとか対応できたようだ。
今回もまた実践の過程でいろいろなことを学んだ。あまりにも関係ないっていうかGT以前すぎる問題については「外伝」に記した。もしかするとあなたも落ちるかも知れない意外な罠かも知れない。
だが最大の教訓は、「Web検索のキーワードの選び方」だった。固定観念で特定のキーワードやキーワードリストに固執してはいけない。あるときはピンポイント、あるときは大風呂敷、あるときはイモヅル式に手を変え品を変え調べていくと、思いもよらぬところで思いもよらぬ情報にヒットすることがあるということを学んだ。
それにしても、もし「SolarisではできたがLinuxではできなかった」だったら、「OSによっていろいろ違うんだろう。おわり」だったかも知れない。Linuxでは当たり前のようにできることがSolarisでできないというのがどーもくやしいっていうか・・・・SolarisならSun Grid Engine使やいいもんとか言うのも、負け惜しみみたいで納得いかないっていうか（使ってみたいけどいずれ絶対）・・・やはりこれは、
なのだろうか。愛はネバーネバーネバーサレンダーだヨ、カントク（ホントに正しい結果でてるかどうかもわからんくせに偉そうに・・・）