2011年7月29日金曜日

ML110G6 on Xeon 3430

これが ¥29,800 とか云うのだから、痺れてしまうねぇ。
ディスクレスだけれど。
ML110 G6 BM101A Xeon X3430 2.4GHz メモリ1GB DVD-ROM HDDレス OS無し



今までこの手の安価サーバはXeonなんて載ってなかったんだから。まあ SandyBridgeの安価なMPUが主流になるとわかってくると LGA1156-XEONは微妙な立場。 とはいえ、LGA775 / Celeron430 の3倍のエネルギーで4倍の性能があるから、僕の納品先では多分有効。今時CeleronでWebサーバなんてどんだけ待ち時間で客の入りをロスっているか分からない訳ですが、そういう選択をしちゃうんだよねェ。止むに止まれぬ選択だとは言え。


WD/RE4 gmirror したマシン・メモリ16GBを搭載して make -j20 buildworld/buildkernel を連続処理した結果
20:53:49 --> 21:20:52  ほぼ26分でした。 timeとコンパイルログを取りながらの結果。
time の出力: 1624.00 real 4392.30 user 511.73 sys …

/dev/nullにログ捨てたらもっと速く終わったかもしれない。

FreeBSD8.2 gmirror install

HP ML110G6 に 保険替わりに HDDx2 で FreeBSDを インストールをする際、ハードウェアRAIDをつけてなければ、GEOM Mirrorを選択するのが弊社の習わし(?)なのですが、やはり手順上次の方法は出来なかったのでご報告申し上げる次第。

1.Install用DISKで起動する。
2.取り敢えずFIXIT選択メニューまで行く
3.FIXIT用LiveFSディスクを予め用意して FIXIT
4.FIXIT中に次のような操作。

 → # chroot /dist
# mount -t devfs devfs /dev
# gmirror load
   # exit
# gmirror label -v -b round-robin gm0 /dev/ad4
# gmirror insert -v gm0 /dev/ad5 (ata2-slave??)

5. FIXIT終了
6. さてインストール媒体を探させてみる → ad4/ad5 げげーん。

ということで、sysinst は mirror/gm0 とか探さないらしいと判った。
この辺り、設定ファイルか何かでいじれるんだろうかねぇ。

今回の納品の前に収めた機材の場合は、HDDx1 だったので、sysinstでディスクを切るという手間を、起動中のコピー元サーバに刺して実行。その後 make installworld をしてみた(DISTDIR設定をする)。実は、こっちの方が手間がかかった(初回のsysinstがディスクを全部umountして終了しやがったので、コピー元のサーバがパニックして再起動になった)ので今回はやめておいた。

オリジナルインストーラを作って最初から必要なものを自動で生成してくシステムを作っておいたほうが良さそうな気はしてきてる(管理してる*BSDサーバが30台近くなると入れ替えは毎月あってもおかしくない)けど、どうしましょ。

2011年7月8日金曜日

iPod touch再入獄…

iPod touch 4G君。 開発ターゲット用に買ったはいいけれど本人の飽きっぽさに放置半分の可哀想な機材です。なんでそんなに使わなくなったか理由を幾つか書きましょう。全部、iPhone4Gに比べての話です。

  • WiFiの電波掴みが宜しくない
  •  酷いと10db位違います。
  • OSとして使えるメモリが少ない
  • iPhone4G 512MB で iPod touch 4G 256MBという話
  • カメラもしょぼい
  • iPhone4Gのフロント(つまりFaceTimeで自分が撮られる側)カメラ程度で固定焦点

    iPod Touch4Gは、iPhone4G-3Gモデム ということではないという事が明らかになると、持ち歩く場所がなくなってきます。

    ということで、僕にとっては残念な機械ですが、それでも音楽を聞くときにはiPhone4よりも良いです。特にAudio出力はしっかり出てくるので、スピーカ直結しても遜色ない音が出ます。そしてiPod(ウチにはiPod Color/iPod miniがあります) でないと動かないアクセサリなんかがちゃんと繋がります。iPhone4ではオーディオ機器を繋げても残念な結果になるのは、無断で店頭でのデモ機にぶっ刺してがっかりしていることがあるので(…なんてヤツ)、やっぱり音楽用携帯機器ってことに落ち着けたほうがいいようです。

    4.2.1の時点でもAirPrintに関しては、色々業務が止まることを怖れて、iOS4.1 で留めおいてある、わたしが今持っているたった一台のiPhone4Gには未だ出来ないことです。で、印刷が使えるようにすると何かと重宝するのですね、他人に渡すメモがすぐに取り出せるし。

    この試みを成す前に自宅のWindowsPCに AirPrintサービス+Bonjours サービスを動かせばAirPrint共有が出来上がります。Bonjoursサービスを止めていたのが原因でMacOSXのプリンタ共有もうまく行かなかったけれど、このあたりを探っていたらちゃんと動くようになりました。 4.2.1でも使えましたがすぐにはプリンター資源が見つかりませんでした。4.3.3の方が安定して迷わずプリンタ共有を掴めたようなのでこれも特筆しておくことかな。

    WindowsPC用のAirprintサービスはここ から拾ってきました。

    AirPrint、めちゃくちゃ便利です。コイツがあるなら iPad2をジジババ様に渡して欲しいときゃ印刷して〜というのも案外出来る気がする。

    で、脱獄しても使いにくいってことで結局また再脱獄のために再入獄しました。その顛末を書いておきましょうか。
    実は4.2.1JBの最大の問題点は tethered JB だったことですね。つまりヒモ付き。USB紐を付けてパソコンで操作しないと電源切ったりバッテリ切れなんかで止まってしまうとブートできなくて困ります。JB時に分かっていたことだけれどこんなに不便だったらまた再脱獄を出来るようにしてUntethered環境になる方がいいはず。

    再入獄の時は、JB時に設定した /etc/hosts とか色々邪魔するものが多いんで注意。ここでハマって出られない! と16xxエラーで死ぬのです。

    iTunes10.3+4.3.3.ipswがあればとりあえず抜けられますが、/etc/hostsを見直しておきましょう。 今日のところは入獄したところで終わり。

    2011年6月5日日曜日

    NagioSQL/NdoUtils

    最近、Nagios関連を再整備中。

    GUIで簡単に設定できる"NagioSQL"とログを管理できる"ndoUtils"
    FreeBSDで嵌ったところを書いておきます。

    1 NagiSQL/portsで突っ込むときの注意(ツカ今の時点では出来ない)

    perl5.8だと今のバージョンはちょっとダメなので、5.12にする。
    今のports(2011/06/01頃)はpear/peclのインストールパッケージの
    判断が変だから、ports使わない方が良いです。ダウンロードして、
    野良で突っ込んでおいたほうがマシです。PHP5.3.6に対応してない
    portsなのかもしれぬ。


    2. ndoUtilsのユーザ関連について

    Linuxの場合だとtar-ballから突っ込むパタンが多くて、個々の
    流儀があるが、portsでは"nagios"一辺倒なので、他のユーザ名を
    使ったりしないこと。スクリプトを全部自前で書き直す根性がある
    場合に限り何をしても構わないけれど、nagiosがブローカに渡す時点で
     齟齬をきたして

     Broken Pipe

    なんてしょーもないエラーで止まってしまう。ブローカっつのが
    くっそ無愛想なのでたた殺したいがそれは仕事をしてもらう関係で
     我慢我慢。

    3. mysql について

     postgresqlでも動くものもある(ndoutils)が、NagioSQLが対応しない
    仕方ないので、mysqlを入れておく。mysql55をさっくりと入れられるのは
    これまでの付き合いが0だったからいいのだが、やはりよく分からないので
    phpMyAdminがあると便利だった


    なんか堕落の一途をたどっている気がする。
    以上

    つかndoutilsを使って監視サーバをまとめるとかやってみないと
    意味ないんだよね。

    2011年5月30日月曜日

    同時多発障害?

    同僚の管理案件が相次いで故障しているとの連絡。
    明日のミーティングでその詳細が明らかになるだろう。

    2011年5月26日木曜日

    FreeBSD8.2への移行(2)

    FreeBSD6.4環境が幾つもあり、更新が大量に発生したので
    取り敢えず注意点を幾つか書くしかなくなる。

    ・6.4からの移行は7.3を経由すること。

    8.2をコンパイルするために必要なライブラリが7.xからでないと作れない模様。
    GCCコンパイラが切り替わっているのもあるし、インクルードファイルやらが足らないなど色々問題がある。6.4では8.2で必要とするものがマトモには作られないので、8.0の頃うまくコンパイル出来たと思ってたものは大抵ライブラリリンクが壊れてて動かない。8.2にもバージョンが上がるとその辺りのミスは排除されている。

    ・8.2環境に上がって古いライブラリをリンクするものが上手く動かないことがある。

    4BSD->ULEスケジューラに変わったこともあり、バイナリ互換で動くようになっていても、常駐するスーパーデーモンやらデーモン系の動きがいつの間にか刺さって生きたふりで、実は死んでいることがあるので、すぐに再構築するほうがよい。

    ・make buildworld に成功しているようでしていない場合もある。

    稀にそういうシステムもでる。 make.confに手をいれている場合は要注意。make.conf を更にしておいたほうが無難な場合もある。 ライブラリが正しく生成されない、必要なファイルが無いなどの現象で、8.2環境でのportsupgradeなどに支障をきたすことになる。現実に、ipsec-toolsなどはlibtoolが定義を正しく拾えないなどの問題が起きた。二度目のmake buildworld insatllworld により、環境が正しく設定された。

    ・portupgrade を 正しく動作させるには?

     まず、databases/db4{1-8},databases/ruby-db,lang/ruby18 は再構築しておくこと。 oniguruma のライブラリが2.x系から、4や5にアップグレードされたことで、構築できない場合がある。rubyで日本語言語処理をするシステムを導入しないならば、onigurumaでの
    国際言語対応正規表現は外しておくが無難。 

    cd /usr/ports/{$target} ; make clean all deinstall reinstall のワンライナーで、大抵入れ替えられる. 最後に、portsupgrade を更新し、

    (nohup portsupgrade -ayfr --batch 2>&1 >/var/log/portupgrade.log & )

    などとしておけば、更新できなかなった物はそのままに、コンパイル出来たものが
    更新されているだろう。

    ・qmail-scanner 系などの portupgrade は問題。

     これは上記の自動portupgrade 処理で引っ掛かるようである。当面、pkgtool.conf の IGNORE 節に加えておくのが良いと思う。perlライブラリが更新し終わった段階で、手動で更新するのが吉。

    ・古いライブラリの扱い。

     消さないほうが無難だろう。古いファイル (cd /usr/src; make check-old-files ) で引っ掛かるものは、すべて消してよい。寧ろ消しておくべきだと思う。

    ・古いライブラリを参照するports の管理から外れているものなど。

    portsは、6.xでほったらかしにしていると、もうすでにディスコンとなっているものも多々あるので、/var/db/pkg/honyarara のdirectory 丸ごと削除してしまう他ない場合も時折有る。pkgdb -F がささって死ぬようだったら、dbから作り直すしかない。

    以上

    2011年5月3日火曜日

    ESXi4.1 update 1 で FreeBSD8.2/amd64をインストールしてみる

    結果を先に書きます。

    ISOイメージをホスト側ストレージに放りこんでドライブイメージとして用意、
    起動させようとして失敗しています。

    原因が今のところ分かりません。 i386では問題がない。
    困った困った。

    追試というか検証用に手元のPCでVirtualBoxを立ち上げて同じイメージを
    使って起動しようとするんですが、これもまた失敗。

    うー、FreeBSD8.2/amd64のisoイメージのブートレコード、仮想環境に
    使えないのかな?? キチンとコンパイルしたものは動くのだけど。

    仕方有りません 8.1-RELを試してみることにします。

    2011年4月20日水曜日

    FreeBSD8.2への移行

    現時点で仕事をするにあたり、FreeBSD8.2が鉄板で非常に嬉しい。
    7.3→8.2とか、ほとんど何事も無く進んでいる。奇跡だ思う。
    まあ細かいところに問題があるかも知れないけどね。

    今頭がいたい問題は2つ。
    取り残されている6.x系の処分。
    6.x→7.3がかなりの確率で上手くいかなくなってしまっている。
    1月にトライした結果は散々だった。
    多分7->8のために7.xが6.xとの互換性を無くしたんだろう。
    旬のうちにバージョン更新をしていかないとえらい目に逢う。

    もうひとつは、i386->amd64にしたい機材など。
    別にしなくちゃいけない理由はなかったのだが、バイナリ互換でないと
    困るものが出てきた(PostgreSQL9.0のレプリケーションとか)ので
    ちょっと迷って、クロスビルドをやってみた。 で、今絶賛失敗中という。

    楽勝のバージョン以降なんだけど、ハマることが時々ある。
    7.3->8.2にするときの注意点はこんなところなのでメモ。

    1.make はまとめてやるべし。
     まとめてやらないと忘れてしまうことがある。
     管理機材が多いから仕方ないとはいえ。

    (cd /usr/src; nohup make buildworld buildkernel 2>&1 >/var/log/mkwk82rel.log & )

     とかいっぺんに回して放置。

    2 インストールするときもまとめてやるべし。

     上に同じ。

    3.インストールしたらログアウトするな!(絶対)

     ログアウトした途端に 大変困ったことになる。
     新しいヴァージョンでワールドが突っ込まれているのに
     カーネルがどうにも対応できてないまま生きてるから、
     ログイン出来なくなるはず。
     ”Could not determine audit " なんちゃらというメッセージが
     コンソールに現れて一切ログイン出来なくなる。
     一台、そーなった機材があったけど、コンソールにroot-shellが
     たまたま残っていたので色々試した挙句、リブートすりゃいいって
     気がついて再起動した。 再起動したつもりだったのだね。

     最悪はマシンのあるところで、直接電源を落とせるようにしないとだめかも。
     リモート・シリアルコンソール+リモート電源コンソールなんてのがあれば別。
     でも、インストールが終わったら四の五の言わずリブート一択。

    だいたいこんなトコロですか。

     .

    2011年4月18日月曜日

    OpenOffice daemon 化について

    某処にて、OOOでフォーマット処理をしているサーバがあるとのことで、
    取り敢えずソースからこしらえて、立ち上がるようには作ったけれど、
    何故か、自動起動後OOOがデーモンになってもソケットを開かない。
    使えないということで手動つかターミナル/shell経由でやると開く。

    困ったので調べた。

    http://community.nuxeo.com/5.3/books/nuxeo-book/html/admin-openoffice.html

    ここから、oxtをダウンロードして来て入れてみたら動いている。
    しかし謎な仕様だ。Javaだからバイナリ互換なんだろうか。

    oxtがよくわかってないので調べたほうがいいですか?

    2011年2月26日土曜日

    引越しツール

    何度かソフトウェアRAIDのメンバーディスクが壊れたり、RAIDのそのものの容量が足りないなんてことはサーバ管理では日常茶飯事なので、緊急修理が終わると安心して暫くは放ったらかされることもある。そうすると本当に引越しをしないでだらだら運用してしまうのでよろしく無い。思いついた頃にはまた再度ファイルシステムをコピーしなくてはならない。ツールがあった方が楽だ。

    ツールを考えたので取り敢えず出してみる。これはファイルシステムの引越しを単純に行うだけのツール。すでにディスクの設定の殆どは終わっててアクセスできる状態になっていることが前提だ

    1./etc/migfstab

    こんな形式のファイルを作る。移行先は何らかのファイルシステムにマウントする。

    移行元物理パーティション 移行元ファイルシステム 移行先物理パーテーション 移行先ファイルシステム

    例:

    /dev/mirror/gm0s1a / /dev/mirror/gm1s1a /mnt
    /dev/mirror/gm0s1d /tmp /dev/mirror/gm1s1d /mnt/tmp
    /dev/mirror/gm0s1e /var /dev/mirror/gm1s1e /mnt/var
    /dev/mirror/gm0s1f /usr /dev/mirror/gm1s1f /mnt/usr

    2.migration.sh

    #!/bin/zsh

    while read i
    do
    echo $i | awk '/^\//{ print "/sbin/newfs -U " $3 }'
    echo $i | awk '/^\//{ print "mount " $4 " " $3 }'
    echo $i | awk '/^\//{ print "dump -L -0 -f- " $2 " | ( cd " $4 "; restore -r -v -f-)"}'
    done < "/etc/migfstab"


    使用法: いまんところ、サブシェルに喰わせるコマンドを吐き出すようにしているから、シェルコマンドラインにリダイレクトすればよい。

    何が行われるか確認したい場合は、単にシェルスクリプトを起動すれば良い。

    例: migration.sh | /bin/zsh


    10分くらいで作ったけど、何回使うんだろうか。これから出番が増えそうなので(汗 事故が無いように願いたい。 

    2011年2月25日金曜日

    プロクルステスの寝台 〜 ITに対する投資はなぜ大切なのか。

    賢明な読者なら、当然その理由は判っているだろうが、最近この手の投資渋りが弊社の顧客である中小企業に目立って来ているので敢えて一つ書いてみるものである。

    1。情報インフラに対する過剰投資に対する懸念

     現状で情報インフラに対する過剰投資が起きている現場があるとしてどのような弊害があるだろうか。 過剰投資そのものを抑制する理由はその投資に対するリターンが明確ではないからであろう。 明確ではないどころか快適性に寄りかかって業務の本質を外れると考える向きもあろう。無論景気拡大が見込まれない場合の投資は慎むべきであるが、人的資源の質的向上が望めない現状で、人的資源を直接サポートする情報機器への投資が過剰に見える場合も少なくない。しかしそれは見当違いも甚だしい場合がある。「自分が知っている」と考える範囲でさしたる問題が見つけられない為に「投資の必要が無い」と考えてしまうのである。創業者世代はその点で「知らないものは専門家の判断に任せるべき」という安全則に従って一見過剰投資であってもそれがインフラならば当然であるという考えで来たのだが、その後から続く、次世代の経営層の担い手は、生まれた時から恵まれた世代であり、苦労して手に入れることも少なかったがために、手軽に使えるPCが普及したこと、つまり家庭一般向けに普及したPC機材の価格の低下に眼を奪われがちである。「信頼性」「即応性」という面を考えることはあっても、以前のような高額な機器でなければならない理由がなくなったために、その実質の価値そのものを過小に見積もっているようにすら見受けられる。ゼロアドミニストレーションが進んだ事で、自分たちの知識レベルで対応可能な範囲でのみ利用するという「素人考え」による情報系管理が一般化してしまった企業が多々ある。これらの企業では大々的なIT投資はもうなされないであろう。 無論、サイズにあった企業内情報管理の再構築は必要であるが、その物的、人的コストを甘く見ている事が裏目になっている場合もすくなくない。

    2。現状の問題を単純に理解できる例とは→ 情報量の単調増大にすらついて行けてないこと

     現状の投資対象であるインフラの陳腐化は、想像以上に速い。この数年で扱われるデータ量の増大ももちろんだが、機器の性能が劣化するよりも先に、日々蓄積されたデータが常に捨てられず雪だるま式にふえているという事に尽きる。 過去のシステムでの常識ではあれば「一回〆をおこなった会計データなどは電子的アクセス手段の可能な記憶媒体からパージされる」などの規約によって保護されていた。しかし情報系インフラでは蓄積こそが意味をなすのであり大量の過去資料を保存しておかなければならない事情が年々増えている。

    製造業では常に製造工程の図面や不具合製品の記録写真などを大量に保存して行かなければならないにもかかわらずリーマンショック以来の景気後退に伴って大幅な情報インフラへの投資が十分に行われていないケースが目立つ。


    3。経営層の情報インフラに対する感覚の鈍摩

     現状で情報インフラが充実してしまったと勘違いする企業経営者が増加していると見られる状況には、老化という一言で済ませられない大きな問題が横たわる。無論ITバブルの記憶を忘れないならば、最近かまびすしい「クラウド化」などの耳障りの良い新しいテクノロジーに乗れば良いなどという「まことしやかな嘘」にも、簡単にはのせられないぞというある種の賢さが備わったと自負している方も居るだろうが、現状の「情報量拡大に対する単純なリニアな投資維持」ということすらもなされなくなってしまうのは、非常に危険なサインであるは考える。 光ファイバなどの普及で、既に企業間の情報伝達能力は高まっているし、事実上インターネットやPC無しに暮らす事が一日たりと出来ない現状にあるにもかかわらず、その維持に必要な投資が出来ないという最悪のパターンで進行する企業活動が時折見られる。これは、人間で云えば過度なストレス回避、必要十分な刺激を得ようとする努力を怠って廃用性萎縮の悪循環に陥るのと同じである。企業における神経の劣化により、企業内でのあらゆる応答性が悪くなってしまうのである。具合的例を上げれば、メールなどのインフラに関する予算削減も大問題である。 企業間コミニュケーションにおける電話なども本来個人の職責に関わる内容の質問が主になるのだが、これについても旧態依然たる中小企業では即時には追跡不可能であり、昨今一般化されつつあるメールアドレスで個人識別がなされてようやく、外部との業務に関わる円滑な情報交換が出来ているのにも関わらずである。業務の属人化を嫌っても中小企業のレベルでチーム化分業がなされてなければ、当面業務の執行は、個人の能力に帰されるのであるからこの点が全く配慮されていなければいずれ問題になる。最終的に経営層の情報管理能力の不在があらゆる困難を生じさせるであろう。

    4。現場の悲鳴

    情報インフラの劣化による、企業活動の応答性劣化とはこのような事態の連鎖を引き起こし悪化するだろう。
     
    1) 前線(事務職)に配布されている機材が劣化し、故障もしくは応答が悪いために、従業員の作業環境が悪化する。
    2) 劣化環境に対する十分な補充がなされないため、ある種の業務が滞り、製造能力、競争力を失う。
    3)作業環境の悪化による、従業員能力の低下(作業効率)および士気低下(怠業/サボタージュ)の発生
    4) 部門収益悪化による、更なる投資後退と悪循環

    5。新人職員雇用に際する投資渋りがさらに悪循環を招くケース

     例えば新人職員雇用を行う場合にも、「旧機器があるからそれを割り当てる」という判断が行われるケースを考えよう。この判断がいかに間違っているかは、次のような障害事例によって明らかになる。

    1)古い機材は、クリーンアップされても劣化しているために障害発生の確率が高い。
    2)新人職員は、機材の取り扱いになれておらず障害対応能力を期待するのは大きな誤りである。
    3)古参職員が、新人職員の指導だけでなく、古参職員なら対応可能だったはずの些細な障害対応に狩り出されてしまう。
    4) 新人職員は、職場環境として与えられた機材を見て判断する。充分な待遇を受けてないと誤解し勤務態度への影響が懸念される。
    5)3)と4)により、生産性の低下、残業の増加などの悪影響が高く、新人/古参の別なく職員の士気低下につながる。

    投資によって起きる損失をはるかに上回る損失が発生することは火を見るより明らかである。無論新規機材を割り当てられても、新規雇用者の能力が発揮されるまでの期間は全く無駄になるかもしれない。だがなにより新規雇用者が些細な問題で躓く可能性を小さくすることは組織の強化につながることを忘れてはならない。
     
    6。最低限行われるべき投資とは何か。

    下記の点については、即時手当てされるべき内容であると考える。

    1)5年以上運用したPCの撤去、新機材の導入
    多年利用したPC環境は、すぐに利用しやすくても、物理的な取り扱いデータの増加に耐えることが日々困難になる。いずれ交換しなくてはならないのであれば、溜まりすぎる前に行うべきである。壊れたら何倍もの労働時間を損失し特別な処理費用を発生させる事は明白である。計画的に交換すれば、予算内で安全に処理される。損失する時間も十分に計画されていれば小さくできる。
     
    2)サーバの強化(計算力、容量)
    無論、利用している情報ファイルの整理は必要だ。しかしそれを整理する時間より新しい機材に置き換える方が人的資源を節約できる事は皆よく知っているはずだ。増大する情報を瞬時に取り扱えるだけの性能がサーバに無ければクライアントを新調しても無駄になってしまう。だから、1)で行った新機材導入と同時に新サーバを追加するか取り替えること。

    3)新しい種類の端末(スマートフォン/タブ型)に備える事
    現場での新しい情報処理がブレークスルーを起こす事はまだあるはずである。Excelは手軽な数値計算の一般化で革命を起こしたが、次にくるであろう革命は、タッチパネル型/携帯機材の普及によるものであると思われる。 タッチパネルのついた高速な処理可能な端末は今までのタッチパネルダム端末とは桁外れに高速で大量の計算が出来る。音声認識や人工音声なども楽々扱える。それらは状況判断に必要な大量の情報を瞬時に整理し現場の作業員をアシストする事になるだろう。この数年で普及したスマートフォンが外出の際のあらゆる情報をその場その場で即座に取り出せるようになって来たように、現場に持ち込んだFA対応スマートタブレットが、故障状況、利用状況、製品情報、過去履歴などを示して作業者を支える時代が来ている。そのようなソリューションは安価に提供されるので利用しない方が困難になる可能性すらある。今は手元になくとも時期が来たら直ちに投入可能なだけの知識とインフラが必要である。無線LANインフラなどの充実が必要になってくるかもしれない。

    4)投資によるリターンを正しくとらえる事。
    今の時点で、現場に新しいPCが来てもほとんどの能力は使われないはずである。私の感覚で云えば3年前の機材でも十分仕事になるだろう。そういう投資は一見無駄かもしれないが3)で発生するであろう革命的な情報の増加に従来インフラが耐えられなければ意味が無いのである。画像データや大量に集まる数値データを図式化するアプリケーションの為の投資である。そして現状維持の為にも新陳代謝の大事なキーになる機材交換が機材の属人化を緩和して「個人のツール」から「会社の仕事道具」に変容させるのに役立つ。

    5)専門分野における投資の必要性の理解。
    一般業務におけるIT投資が鈍ると、専門分野でも鈍ってしまいがちである。これはITバブルの反動であり無計画な投資が行われたことによるが、専門分野におけるIT機器はもっと問題が切迫しており競争力そのものになってしまう。従業員のもつ能力を削るのは、この手の ”プロクルステスの寝台”である。


       
        

    2011年2月13日日曜日

    iPod touch (iOS4.2.1) JB

    iPhoneに続いて、買ってしまったのがiPod touch 4G....
    かなりiDeviceに魅せられていることは間違いない。
    iPad2が出てきたら買う可能性が出てきた。

    とはいえ、弄るのが趣味な人間だから、JBしないでいられなかった。

    このiPod touchは、時期的にSHSHが得られず、いずれにしろ tethered JB という選択肢を取らざる得ない事態。 ちょっとイライラするだろうけど我慢。Cydiaが動かない、白アイコンになっちゃうなんてJB初心者はがっくりするだろう。とりあえずそんな状況でも抜け方があるので、4.2.1からのJB-ORZerは、過剰の期待しないで読むこと。

    何をしたか?

    まず状況チェック。 JB環境としては、iOS4.3bあたりを持っていさえすれば容易にuntetherd に成り得るが現状ではipswを入手していないのだから、4.2.1でやるしか無かった。

    iPhone4で利用したお手軽なGreenPois0nは、どうもiPod/touch4G のiBootが出来ないらしく、redsn0w0.9.7b6を使ってみた。現状ではこれでしか書き換えられなかった。

    まあ、MS窓環境で試してみようかと思うが、最近XPの実機環境に戻れないくらい快適な移行先の環境になってきたので、やらないかも。


    ・DFUモードとリカバリーモード

    母艦としてWindowsXP環境しかなかった時点では、よく勘違いしていた点。 DFUとリカバリーモードは WindowsPC版のiTunesでは区別ができないし、そもそもWindowsPCでは、DFUなのかリカバリーなのかを見分ける簡単な方法がなかった。

    無論、「iTunes→USB」というリカバリーを示すイメージが表示されるのがリカバリーモードだが電源が切れた状態でのリカバリーモード突入状態か、DFUなのかは、つないでみないとわからない。

    手順を間違えれば、容易にリカバリーモードになってしまうし、ただの電源オンオフになることもしばしばあある。MacOSX環境があれば、つないだ時点で識別できるので便利だ。

    スリープボタン(長押しで電源電源が切れる)ボタン、ホームボタン(丸)を次の手順で操作するとDFUになる。

    1.iTunesが起動しないように、iTunesで当該iデバイス接続時のiTunes自動起動をオフする。
    2.iデバイスの電源を切った状態で、USBケーブルで接続。
    3.スリープボタン2秒押し
    4.スリープボタンとホームボタンを同時押し10秒(液晶が、基盤ごとパワーオフされた瞬間光る)
    5.スリープボタンを放すが、ホームボタンは押しっぱなし。15秒
    6.画面が黒い状態がDFU状態。

    DFU状態は、JBの際には重要なポイントだが、意味もわからないヤツにDFUさせるための手順をわざわざ
    こったものにするのがJBツールの常らしく、DFUになっているかどうか確認してはいないようだ。
    すでにDFUになっているが、JBツール側とのマッチングが取れてない場合には動かないものもある。

    ・IPSWとカスタムFW

    カスタムFWについては、大して知識がないので割愛するが、Mac環境ではIPSWを展開して色々と準備作業をすることができる。おおかたのJBツールでは、アップグレードに使われるIPSWファイルに改変を加えて、Systemが最初から持っているipswローダ部分をまるごと使っている。最近ではアップルコンピュータの認証を得ないIPSWを流し込めないため、認証サーバを上手く偽造するツールがある。

    いずれにしろiOSは、MacOSと互換性があるため、MacOS上でカスタムファイル、パッチャーを追加して流しこむのは楽だ。WindowsPCでは必須のUSB/TCPMUX機能を持つiFunBoxに相当する便利な道具はなく、iPhoneExplorerが今のところファイルのやり取りをするだけだが、まあそれなりに使える。

    ・TetherdJBとはなにか。

     要するに普通にJBプロセスして行くだけでは、機器の外に直接アクセスするような実行ファイルが認証されないモードになったように見える。インターネットブラウザのSAFARI、Cydiaのようなものが正常に起動しない。しかも、redsn0wでは、JB時に排他的な選択肢として「Tetherd」の選択ボックスを用意している.  つまり1回目には、本体のJBにつながるファイルの転送など、2回目にはTetherdJBを選択することで辛うじて使えるものになっている状況である。通常は2段階のJB関連作業が必要になり、この作業はシステムを再起動するたびに行わなければならない。


    ・Tetheredの罠

     非常に使いにくいのは、CydiaやSafariが無効になってしまうTetheredの罠である。Cydiaがアップグレードを要求した際にリブートしたのだが、この際も一旦半ばJBと同じDFUを経由して、TetherdJBとなる。これでは仮出所に近い。まあ、所詮、iPodは副次的な機材だし手軽な開発ターゲットとして家に置くのだから別に構わんのだが、気軽に電源も切れないのはちょっとどころの不便ではないようだ。

    現に、SBSettingsなど必須アイテムをインストールする際にも発生する。シェルであるスプリングボードに直結するSBSettingsをインストールにしたら、もう再起動はしない。 この場合は、絶対に再起動時はDFUに落とし込まなくてはならない。 そして、その度に赤雪の世話になり「Tetherd Boot」を選んで動かせるようにすることになる。 最初の最初だけれど不便すぎるし、ココロ細いJB初心者はここで文鎮化したと判断して修理するかの判断を余儀なくされるはずだ。この改変時点でアップル社の意図通りで対JB作戦はかなり成功しているように思われる。


    ・しかもCydiaは相変わらず・・・・

    配布している MobileTerminalが古いままなので動かない。結局Cydiaが動くかどうかというのは、Tetherdで有るか無いかを知るための道具に過ぎなかったような。 今や、業務的にもMobileTerminal/OpenSSH(daemon) が動けば、用事が足りてしまう私にはあまり関係ないかもしれない。MobileTerminal風な機能をAppleが用意してくれれば、JBなんてしないでそのまま使うんである。隠すというのはスケベごころをくすぐる悪いものと言おうか。

    2011年2月12日土曜日

    DHCP 漏れる

    複数個のDHCPで管理されていたネットワークを統合するのは、
    DHCPの設定をまるでパズルのように切り替えていかないとならない場合もある。

    2011年1月30日日曜日

    Sophos SBE2.x -> ES4.x(9.5)

    SophosSBE は2011/03/31 End of Support となるので、更新作業が必要になる。
    弊社顧客ではコンプライアンス要件上不可避なシステムとなっている。手間が増えて
    今回の更新作業はかなり不快感を禁じ得ない。

    どうしても複数回の作業が必要となるのでメモ代わりに記す。


    1。変更点

      CIDs の展開場所が、Documents and Settings に移動した。
      今までの¥Program Files¥Sophos 以下にあるマシンローカルで扱うフォルダではない。
     
    2。変更点ではないけれど注意点

      XPマシンでは「簡易共有」が有効になっているマシンに配信機能を持たせることは不可能。
      また配信を受ける側でもよろしくない。 

      

    インストールに失敗しました。 日時 コード 説明
    2011/01/30 1:44:25 00000034 インストールプログラムの起動元である共有フォルダにアクセスできませんでした。(これは「アップデートポリシー」で指定した場所です。) この原因として、共有フォルダをホスティングしているコンピュータのネットワーク接続が十分でない、コンピュータの保護 ウィザードで入力したインストール用アカウントに共有フォルダへのアクセス権限がない、または共有フォルダが存在しないことなどが考えられます。


    などとなるため、ローカルワークグループでの運用は容易ではないが、SCCのインストール後に、
    アップデートポリシー用のユーザー名とパスワードを Sophos Control Center バージョン 4 で変更する方法などを参照して、ワークグループ内で定めた共通アカウントに設定することで回避できる。とりあえず簡易共有は外すことが必要。

     8192/tcp,8193/tcp,8194/tcp のポートが開いている必要も有るとか記述が有る。


    とりあえずテストは完了したので、実運用環境でのテストを開始する。

    以上

    追記:

    8192/tcp → IOR port
    8194/tcp → SSLIOP port

    Sophos プログラムグループフォルダに、
    ソフォスネットワーク通信レポートというショートカットが出来ている。
    そこから読めるデータから採取。

    2011年1月26日水曜日

    X-window

    ふと昔を思い出す。

    X-windowを初めて知ったとき。

    □のカーソルと■のカーソルがある
    仮想端末が複数開いてて別なことをしている。

    まあ、コンソールを単純に分割して4つの処理を
    同時にするのは OS-9/6809 で経験していたんだよね。
    星光電子なんて懐かしい名前が思い出されます。
    SEIKOUって書いてあったけど別に服部時計店、諏訪精工でも
    精工舎でもないんだと気がつくには雑誌をどれだけ読んだかな。

    でもあれはGUIじゃない。 本物のパロアルト風味は
    あの、Xeroxから生まれてきたあの素っ気無い白窓は
    やっぱりその時に初めてであったモノだと思う。

    場所は覚えてないけど、たしかにあった。
    でも、1994年頃には、自前のデスクトップでX窓は
    開いてたと思う。 なんでMSのWindowsもやりながら
    こっちも開いてたんだろうとは未だに思う。

    2011年1月24日月曜日

    virtualbox-ose

    今後なるべくなら触らないで済ませたい
    WindowsXP関連の数々のシステムを
    どうしても温存しておかないと済まない状況。

    こんな時システムの寿命をさらに延ばせる方法が
    あったなら!

    ”仮想化技術はレガシーシステムのためにある!”

    すでに、死んだシステムと言われて心なきものより
    鞭打たれているオフコンも仮想化の棺に入れられて
    半永久に保存されて行くのです。

    そう、こんな棺をあなたも欲しいですか?

    最近、FreeBSD でも、VirtualBox-OSEがしっかり動くので
    先週末トライしてみました。

    とりあえず報告だけ。一寸忙しいので後で詳細を書きます。

    2011年1月21日金曜日

    快適環境へ

    MacOSX は、素晴らしいOSである。
    ちゃんと動けばこれほど磐石な土台に作られたものもないと思う。
    ちゃんと動くようになってきたから、ますます惚れ込んでしまう。

    紆余曲折ありながらもこれで仕事できるじゃないか。
    これのエヴァンジェリストに転職しようかと思うくらい。

    それまでに嵌った点をいくつか。

    まずは、10.6.6に行けないkextは捨てなくてはならない。
    捨てるべきは、SleepEnablerが筆頭である。
    これは物理的に別ドライブにあっても、起動可能な側にある
    のを読むようである。スリープモードが使えないがまあ仕方ない。
    この機械はACPI電源管理がおかしくなっているのだから、諦める。
    TonnyMacには世話になる。でもVoodooをむりやりSLEに投げるのは
    辞めてほしい。探しづらいし怖い。

    myHack11があればとりあえず起動は問題無い。ブートセレクタは
    多少なりとも必要だとおもう次第。

    あと私の環境ではVoodooPS関連はご遠慮申し上げる次第。
    最初は動いて面白かったのだが、PS2キーボードを捨てて
    USBにするほうが楽だし、コスト的に安かった(1000円前後)から。
    HDAは10.6.5以前でしか動かないし、もともとそんなモノがない
    以上無駄だ。

    私は二度リテールDVDからシステム再インストールしてシステムを二つの
    物理ディスクに入れているため、交互に起動して修正できるようになったが
    知らないとかなり苦労する。同じ環境のシステムが二つ以上必要になる。

    仕事でも何でもそうだけど、使えるようになるのに1ヶ月以上はかかる。
    そして複数台無いと安心していじれない。 何にでも言えることのようだ。

    2011年1月19日水曜日

    SIGSEGV 11

    原因がわからないまま長らく放置していたシステムの欠陥。
    メモリリークが3つも見つかっている。

    シチュエーションを書くとこのような状況である。

    1.ESXi4.1 で動いてる
    2.FreeBSD7.3
    3.死ぬのはapache2.2.17/httpd
    4.PHP5.3.4/守護神パッチ
    5.firebird

    この環境で valgrind を試してみたところ3箇所で
    何らかの障害につながるリークが見つかる。

    上記の環境組み合わせのうち、ESXi4 ではない環境では
    まずメモリリークが起きない。

    毎回 core吐かせる設定にしたら、毎回違うcoreで違う場所であるが
    きちんとページイン出来てない orz なコードで死んでいる。

    しかも、この壊れるのがページ離脱時なので実害が見えない。
    で、メモリリークがかなり溜まってくると仮想側のシステムが
    どーにかなるんだろうが、だいたいその時点でハングしている。

    一応、現在の結論はIOエラーに落とし込んで来ているものの、
    実証環境がレアな状態であるのが全く悔やまれる次第。

    切り分けがハードウェアに近いところでのエラーである為に、非常に追いづらい。
    というか、ハードウェアを疑わざる得ないが、単にハードウェアのみならず、
    仮想化環境であることが、問題を複雑かつ解きにくくしている。

    vmwareではない非仮想化サーバでは決して起きない現象であるから、
    vmwareを止めろという結論を見たくないのだが、現時点では
    ESXi4.1で色々なシステムを統合しようなんて話は当分できない。

    ハードなアクセスがあるからこそ、実績のある仮想化環境を試したのだ。
    こんな結論が出るのは残念だ。

    2011年1月11日火曜日

    Xcodeで困る

    結論書きます:

     1。 ちゃんと$99払った方が楽だ(笑)
     2。 脱獄なんかしない方がもっと楽だ(笑)
     3。 ジョブズに逆らうな(泣)


    追記’

     あんまり敗北宣言するのも恥ずかしいので取り敢えず
    コンパイルと無理矢理のデプロイにこぎ着けた事は書く。
    Xcodeが手に入っただけでは3つの問題がある。

     署名しようがない。
     署名するにもそのための証明書が無い。
     証明書なしではデバイスプロビジョニングは自動化されない

    root権限でファイルアクセスできるJB済みのiDeviceなら最後の
    関門はサードパーティのツールで抜けられる。

     問題は電子署名済みの証明書である。
    本来ならば、Appleから認められたデベロッパメンバとしての
    署名を買う事になる。 勿論公的に配布可能なアプリケーションを
    作るならAppStoreに陳列される必要があり、Appleの厳しい検査に
    合格したアプリケーションとしてのお墨付きをもらうのが正しい。

     だが、私的かつ実験を繰り返すレベルでは不要だと思う。
    配布も限られた間で行うのであれば、自己署名で問題は無い。

    そもそもコードの電子署名は誰が作って誰が許可したかを明確にする為に
    あるので、作成者が分からないものを使わせないための仕組みとして
    まじめにApple社が取り組んだ成果であると考え評価しても良い。この辺り
    業界で先んじて行ったと思われるマイクロソフトは実にいい加減な態
    度で臨んでいたので、当時はあまり電子署名付きプログラムであるかない
    かを認識することはなかった。むろん最近ではちゃんとコントロールできているが、
    Windows2000の時代にはほとんど無理だった。 つまり配布プログラムの
    バージョンコントロールを徹底する事は物理的に出来無かった。当時の流通量と
    署名識別のための認証局アクセスコストは今より遥かに高かったからだ。

    Xcodeで作られるバイナリファイルに電子署名するにあたり、MacOSXには、
    キーチェーンアプリケーションが付属しているからこれで署名した電子証明書を
    発行することにする。自己発行証明書は、問題があるとされながらも、一切の
    権威付けが行われてないというだけで、暗号生成/復号に役には立つ。否認防止も
    出来ないから、まさにオレオレ証明書である。

    まず、自己発行電子証明書を「コード署名」目的で作成する。名前は適当でよい。
    そして「ログイン」キーチェーンに加えておく。

    Xcode側で、この証明書を識別するように設定する。
    また、自己発行証明書を用いるように細工もする。

    ここににある手順を行えば、コンパイルまでは出来る。

    デプロイは、iPhoneExplorerなどで行うといいだろう。 もしプロジェクト名が
    hogehogeなら hogehoge.appという梱包済みファイルを選んで、
    /Applications/ 下に配置して、

    ldid -S /Applications/hogahoge.app/hogehoge

    などとする。

    2011年1月6日木曜日

    FreeBSD6->7 失敗

    また失敗やらかしてこんな時間ですorz.

    敗因いくつか書きます。

    1. 大昔の6.4インストール時点での手抜き

     初心者のごとくsysinstal に盲従したことが原因。
     / パーテーションがあまりにも小さい見積りになりがち。
     512MB なんて全く足りません。 今4GBくらい当てて
     何か激しく/rootあたりに作る処理が発生しても問題が
     ない様になっています。

     40GBのHDDの時代でも 1GBくらい割り当てても良い
     はずなのに、ディスク容量がとても足らなくなり、
     出来ていて良いはずのファイルが正しく収まらない現象は
     他のアップグレード中サーバでも起きていました。

    2. レスキュー対応しなかった。

     LiveImageを何処かにおいておくべきだった。
     このLiveISOの使い勝手はよくないのが常のこと。

    3. 使える動的ライブラリを捨てた><;

     古いライブラリに依存してないと錯覚していた。
     何となく動いていたのが気に入らずブートストラップ
     状態だったのを奇貨として再構築に行けばよかったのだが。
     まあ色々動かなくなり始めていたしカオス状態だったの
     壊れるのは時間の問題だったかもしれません。

    まあ、いずれにしろパーティーションのミスが響いて
    処理が難航し、ついにライブラリがおかしかったので、
    別ディスクにOS(FreeBSD8.1)を入れて、古いディスクからサルベージと
    あいなりました。

    ほとんどのデータは壊してないし / で一番大切な場所は
    全部バックアップしてあったので被害は最小限(時間だけ)です。
    時間として復旧に6時間くらい。 監視機能はまだ復旧しないけど
    インフラとしての機能は戻しました。まあまだ正月休みだったので
    セフセフ。 正月休みじゃなかったらもっと用意周到に
    やります。

    2011年1月4日火曜日

    昼仕事して夜仕事続けるのは

    ねむねむ。

    ちょっと無理らしい(笑)
    珍しく日勤者風な時間…年の始めだし客先も閉まってるんで
    取り敢えず働くふりをww見せておかねば。

    とか云って、あまり儲かる仕事になってないんですよね。
    メンテナンス仕事なんてのは、トイレ掃除とかと同じレベルです。
    あれが楽しいとか言うのは、トーマス・ソーヤーに騙された連中。

    まあ、やっぱりというか暇を見つけて遊びの要素を探しますが、
    冬休みにOSX86でノウハウ固めちゃったら、後は検証あるのみです。

    例えば…

     ・CPUIDを知らない(Cerelon G1101)とかは即起動却下される。

    とかいう話を繰り返すわけですが、メモリとCPUがあれば取り敢えず
    動きそうです。また3万投資すればなにか動かせるでしょう。
    とはいへ、MacOSXのマシンが複数台あってもまだまだ使い切れません。


    MikuInstaller

    なかなかWineもIntel-VT下ではサックりサクサクという感じです。
    というか、VTじゃなくても、ネィティブコードで動きますはずです。

    問題は今動かしているMacOSXが64ビットで動いてるのか?という点ですが
    メモリを8GB積んで認識する以上は大丈夫なんでしょう。


    2011年1月3日月曜日

    iOS: launcd ->sshd

    iPhoneでsshdを動かすと、22/tcpが開きます。
    これは気持ち悪いんです。

    だから別のポートにしたかったので launchd経由である
    ことを知らないまま、/etc/sshd/sshd_config にポート番号を
    書いたけど見事無視でした。

    まあ、inetd経由だったらば、あの記述はガン無視されるの知ってたよ…と
    今更ながら言い訳をします。

    /etc/service で ssh の記述を換えたら無事変わりました…
    そこで問題がひとつ。

    最近 i-Funboxという便利ツールが WindowsXPで動いてますが、
    こいつが USBtunnelをつくることが出来るようなのです。しかし
    22/tcpのトンネルに固定されているよーで、この変更で動かなく
    なってしまいました orz..

    i-Funboxのトンネル設定を自由にできないものかねぇ と今考えてます。

    launchd の設定が /System/Library/Launch Daemon/ (スペル怪しい)に
    あったんですが、sshd 関連は、ここにはなく /Library/LaunchDaemons
    で発見されます。ここはCydiaが突っ込んでいるものの様子。 

    昨日からOSx86化したマシンを放置しているので、そのマシンとの比較で
    さらなる探求が続くものと思われます。

    と、他人事のように。

    あと、launchdは、inetdに化け切ることができずsshdは動かせないとか。
    そのかわり代理に動くサブシステム launchproxyが sshdを起動するようです。
    こーいうものも MacOSXで動かしているから、iOS4でも動くのですね…。
    というか、開発コンセプトがすっきりしているのが分かってくると、
    デスクトップPCと、OSベースが共通であるAndroidや、互換性の高いiPhoneの
    開発が如何に今までの、開発環境の独自性、閉鎖性を打ち破ったかを如実に
    語っているように思います。無論、Microsoftがモバイル機器のOSとPCのOSを
    近づけようと最近頑張って来てますが、すでにかなり引き離されている感が。

    どうなることやら。

    2011年1月2日日曜日

    iOS: launchd

    不勉強なので、iOS系のことは全く研究して
    いなかったコトを白状しなくてはならない。

    とはいえ、Unix系の知識から類推することは全く問題ない。

    たとえば launchd って奴がナニもんだったのかという疑問。
    inetdもないしinitもないiOSの異常さに気がつくのが遅かった。

    opensshが常駐する時点で気がついてなくちゃならんのであるが、
    通常inetdが無いのなら…

    /usr/sbin/sshd -p22 

    なんて設定になっている。しかし、

    sshd -i

    これは、inetdなんかのスーパーデーモン経由での起動を意味している。
    で、スーパーデーモンってのがどこなのか?

    調べるのに、 "ps axl" なんてしてみるわけ。

    UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
    0 7496 1 0 31 0 274780 1292 - S ?? 0:02.07 /usr/sbin/sshd -i

    PPID=親のプロセスID番号が 1 ってナニ?

    UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
    0 1 0 0 31 0 275168 524 - Ss ?? 3:11.26 /sbin/launchd

    あーら、あったよ。 launchd !

    opensshが入ると、locationd が動かなくなる現象があって launchdで起動、再起動を
    やる必要があったのだが、launchdが、socketまで握ってるとは驚いた。

    init + inetd = launchd なんだねぇ。

    という、iOS/Tiger から導入されているのだとか。

    ここ見ても少し勉強します。

    FreeBSD: icu4.x for FreeBSD6.x / Trouble shooting

    EoL な FreeBSD6.4とかまだ動かしている。
    馬車馬にはアップグレードの隙がないからだ。

    で、icu3.xを使うアプリが乗っていると更新ができずに
    二進も三進もいかないのである。先月くらいから。

    現状、icu4.6はFreeBSD6.xではportsからコンパイルできない。
    原因はリンク時のコンパイラエラーである。
    回避策は、FreeBSD6.xがgcc3.4.6を使うことから、gcc46あたりを
    入れて

    CC=gcc46
    CXX=g++46

    をMakefileに追加しておくだけ。

    コンパイルはこれでできる。