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に追加しておくだけ。

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