保守できなくなり、塩漬けにしたままのオープンシステム—。いま“オープンレガシー”が情報システム部門を苦しめている。
…
　1990年代から2000年代の初め、オープンシステムは「早く安く作れる」「新しい技術が使える」「1社のベンダーに縛られない」といった輝きを放ち、“自由”の象徴だった。このメリットを追って、多くの企業がメインフレームからオープンシステムへと開発の軸足を移した。
　だが今、その輝きは色あせ、輝きの裏に隠れていたデメリットが情報システム部門に重くのしかかっている。「早く安く作れる」というメリットは「作りすぎて保守できない」というデメリットに裏返された。「新しい技術が使える」というメリットの裏には「選んだ製品が廃れる」というデメリットが、「1社のベンダーに縛られない」の裏には「組み合わせの制約で更改しにくい」というデメリットが存在した。
…
　メリットを追い続けてとにかく作り続けた結果、振り返ればオープンシステムはレガシーとなって企業を苦しめている。しかし、開発コストとスピードを考えるとメインフレーム時代には戻るのは現実的ではない。

今そこにある「オープンレガシー」 – 記者の眼：ITpro

同記事は、「オープンレガシーを救う七つの鍵」をこの様に挙げています。

1. 運用を立て直す (ISMS、ITILを導入する等)

2. 保守切れソフトを更改する

3. 標準化で範囲を狭める

4. 技術マップを持つ

5. 陳腐化させない努力を続ける

6. 仮想化は一時避難所と考える

7. 所有か利用か、スタンスを明確にする

この中で出来ていないとすれば最優先すべきは、「3. 標準化で範囲を狭める」でしょう。

このご時勢ですしIT投資は抑制気味でしょうから、オープンレガシーがどんどん増えていく状態ではないかもしれませんが、ハードウェアやミドルウェアのリース契約更新、耐用年数、保守期限など、ハードウェアやOSやミドルウェアのマイグレーションは定期的にやってくるでしょう。

これ以上増やさない為にも、情報システム、特にハードウェア、OS、ミドルウェア、インターコネクト（ネットワーク）などのインフラストラクチャ部分の「社内標準化」と、情報システム部門による稟議フローへの積極的介入が必要です。

何より、最適化するチャンスでもあります。
モノによっては、SaaSに移行した方がええやん、と言うモノも結構あるでしょう。
特にコモディティ化が顕著なモノは沢山あるでしょう。
例えばDNS、メールサーバ、勤怠管理、グループウェア、等など。

運用系の人は、世の中の技術トレンドをよくウォッチして、積極的に経営層に具申していかなければいけません。
そのためには、まずなんでもオンプレミスでやりたとか言うこだわりは捨てましょう。
あと、レイヤの違う人と話をするスキル、プレゼンテーションをするスキルを身につけないといけません。
最初はなかなか判って貰えないでしょうけど、場数も必要でしょう。
相手に理解してもらうには、辛抱強く訴え続ける事も必要かもしれません。頑張りましょう。

それにしても、どうも「システム運用」系の人々は地位が低い事が多い。

アプリケーションを作る開発系の人々は元より、運用系にも開発系にもどちらにも生息するインフラストラクチャを設計・構築する構築系の人々よりも、一段下の扱いを受ける事が多いです。

原因は色々あるんだけど、運用系は「売り」に直結して無い事で経営層から軽視され、「技術スキルと単価」から相対的に開発系と構築系から下に見られがちです。（あくまで一般論です）

あと、職責上どうしても「安全側」に偏った考え・発言が多いのも運用系の特徴です。それが仕事の一部だから当たり前だけど、嫌われ者役にならざるを得なかったりします。

運用上見つかった不具合を報告するのも仕事なので (ITIL的に言うと RFC、Request For Changeですね)、これまた喜ばれる事は少ないです。開発者の方々、フィードバックをくれる運用系の人にはちゃんと感謝しましょう。

不具合の対処といえば、原因究明できれば治ったも同然なんですが、それが一番難しいんです。
オープン系のシステム、特にオープンソースを多用していると、何が起こっているかを正しく知る事はあまり重要でないというか、難しいんです。それよか怪しい所を交換してみようとか、そういう運用になる事が多いです。Googleのハードウェアに対する考え方がそうですね。

で、原因がアプリケーションだと判明した時、それを直そうと思っても最新のソースコードどこにあるねんとか、ビルド環境ってどうやったけとか、その言語はもう使える人いませんよとか、ドキュメントないですけど直したとして他との影響が無いかどうやってテストすりゃええねんとか、ステージング環境なにそれとか、なんかガッカリな状態だったりする訳ですよ。

結論として「運用対処の方が安くつくよね」と言う事が結構あります。
それはそれで良いんですけど、運用系の人はちょっとだけ傷つきます。
私もその台詞良く言いますごめんなさい。

運用系側の視点に立つと、開発・構築系の方々の担当するフェーズ（企画、設計、開発、実装、試験）での短納期でやっつけちゃったね的な事とか、コスト制約とか、大人の事情とかでの、ムリのしわ寄せ出てるでしょう的なシステムが大半な訳です。ぶっちゃけた話。

何色々ケチってクライアントや上の言いなりになってテキトーにつくってやがんだこのやろうドキュメント出せやとか、本音では思ったりする事もしばしばなんですよ。

それでも運用系の方々の大半は、開発系の方々を技術的にリスペクトしているんです。自分には出来ない事が出来るから。開発系が良いモノを作ってくれた時なんか、我が事の様に喜ぶもんです。

どうです。愛おしい気持ちにさえなってきませんか。

逆に開発系の方々は運用系の仕事が出来るか？と言えば、オペレーションはある程度は出来ちゃうんです。良くも悪くもドキュメンテーションが運用管理の基本だから。

開発系の方々は、なんとか頑張って研修制度とかを設けて3ヶ月位やってみたらえーんですよ。マジで。運用フェーズの経験が無い開発者の方は特に。

なぜなら、運用フェーズがイメージ出来ない人には保守性の高い成果物なんて作れないからです。さもなくば座禅組んでTCOについて72時間位考えて見てください。

Twitterでは大量のサーバを運用しており、それらのサーバに対してのアップデートは素早く行わなければならい。しかしGitサーバに対するアクセスによってデプロイを行うことには非常に問題があった。

そこでBitTorrentを使ってデプロイする「Murder」というツールを開発をした。Murderは、BitTorrentを包含して内部ネットワーク用にオプティマイズしたもの。これまで約900秒かかっていたデプロイの時間が約12秒になり、75倍も速くなった。

なぜBitTorrentをベースに選んだかといえば、多くのライブラリがあることが理由の1つだ。
…
Murderはオープンソースで作られており、基本的にはPythonのスクリプトとCapistranoスクリプトでできている。
TwitterがBitTorrentで高速にデプロイしている仕組みについて － Publickey

このLarry Gadea氏と言う人も頭が柔らかい人ですね。

優れた技術力を持ちながら、かつ既に有るものは最大限利用すると言うマインドのある開発者には、なかなかお目にかかれません。

加えて、比較的ネガティブなイメージが強いBitTorrentを利用しよう言う自由な発想と、それを許容する企業風土が無いと、こういうシステムは具現化しないんでしょうね。

請負開発がメインの日本のSIerとかでは絶対に生まれないモノだと思いました。

逆に、こういった大規模システム運用技術は、ネットワークゲームとかを手がける企業こそ得意分野なんじゃ無いでしょうかね。

うーん。ネットワークゲーム屋と大規模WEBアプリーケーション屋。なんか似ているぞ。

svc オプション サービス名

参考サイト
daemontools howto

早速テキストに書き起こしてくださった方がいます。ご苦労様でした。
【書き起こし.com】孫正義VS池田信夫「光の道」対談（夏野剛司会）
わたしも一度UStreamで見てはいましたが、今一度全部読んでみました。

光の道も大切ですが、電波の再編は喫緊の課題です。
これは討論のお三方の共通意見でもありますが、司会役の夏野さんがアゴラの記事で詳しく書いておられます。

周波数政策と通信業界の競争戦略　―　夏野剛 : アゴラ

既得権を持つ側のテレビ局や新聞社はこれを報道する事はありません。

今わたしに出来る事は、出来るだけ関心を持ち続ける事と、この事実を出来るだけ広める事です。

「このままでは将来iPhoneやAndroidが日本で使えなくなります」と言う部分は、技術に明るくない人にでも説明しやすいですね。

見逃した方はアーカイブでどうぞ。
「光の道」2 part1
「光の道」2 part2

池田信夫さんも早速ブログに書いておられます。
池田信夫 blog : 「光の道」討論について

ネット上でも賛成意見、反対意見が出始めています。

賛成意見
光の道？いいんじゃない？ – Re:Life
光の道について Sakamori’s Blog/ウェブリブログ
孫正義 vs 池田信夫氏 司会 夏野 光の道対談のUst中継: since20090315
孫正義VS池田信夫～光の道対談 おもしろかった。 : Anti intel !?

反対意見
鈴の音情報局blog 孫 正義VS池田 信夫～光の道対談
ネット社会の闇～Ｂｌｏｇ編～ 光の道構想

私は前半の20分位を見逃しましたが、それ以外はほぼ全て視聴できました。

途中、飯くったり、子供たちの風呂を手伝ったりしましたが、iPadのおかげで視聴し続けることができました。いやiPad便利ですね。WiFiですが、途中で2回位途切れましたが、ほぼストレスなく視聴できました。横に流れるTwitterの更新の早さが尋常じゃありませんでした。

子供たちは何事かといった反応で、iPadから流れるオッチャン達の討論にしばらく食い付いていました。意味は全く判らんでしょうが。

討論は2時間の予定が、結局3時間半弱くらいになりましたが、わたしは熱い討論に最後まで釘付けでした。

前半は主に光の道構想の詳細な計画について、既存のメタル回線の維持費用が高すぎるとか、そんな話でした。

電波行政の問題点、メタル回線の維持の問題、それからITは成長のエンジンだ、と言う点では3名はほぼ意見が一致している事もあり、討論でありがちなかぶせ合いとかもなく、孫さんも思う存分話す事ができたと思います。

それでいて、適度なタイミングで質疑が入り、話の展開が判り易く、司会の夏野さんの仕切りが上手だなぁ、と言う印象でした。

最後の1時間位にはコンテンツの話になり、孫さんから電子カルテや電子教科書のプレゼンもありって議論が白熱してきて、かなり面白かったです。

コンテンツが先かインフラが先かは、卵と鶏の話と似ていますが、私個人は、インフラありきてコンテンツは後からついてくると思っていますし、孫さんみたいに熱い男は好きなので、光の道構想には基本的に大賛成です。

ただ、NTT構造分離の話は、感覚的には賛成ですが、過去の経緯や政治的なしがらみについて知らない事が多すぎて、アンケートでは「わからない」と答えておきました。

電波の再編については、アンケートでも9割5分くらいは賛成でした。
当然私も賛成です。
今の私に出来る事は、この事実を出来るだけ多くの人に伝える事くらいしかできませんけど、応援したいと思います。

高価なHDDクラッシャーがある現場は楽ですが、永久磁石でささっとやられる方や、中にはプラッタを物理破壊するツワモノもおられるかもしれません。

わたしは、フリーでローレベルフォーマットが出来るツール DBANを使用します。
DBAN Download | Darik’s Boot And Nuke

消去アルゴリズムとして米国国防総省準拠アルゴリズム（DoD 5220.22-M）とかが使えます。

まずは、isoイメージをダウンロードして、ブータブルなCD-ROMを作成します。

それから、ローレベルフォーマットを実行したいPCに挿入し、起動してから、
dodと入力しEnterキーを押下するだけ。

これだけで、DoD 5220.22-Mで、全ハードディスクを完全削除してくれるから楽です。
もっとも、古いサーバや、HDDが沢山ある場合は数時間かかりますが・・・

suz-lab – blog: AssemblaでプライベートSVN
(いつも有益な情報を有難うございます)

「Free Repositories」のプランでは、無料で、2GBの容量が使えて 、リポジトリ更新出来るのは自分だけ、リポジトリは公開する事も、非公開にも出来る。
SubversionとGitのみが使える。ちゅうかそれが目的なんで充分ですが、他の有料プランでは、プロジェクト管理に有用なツール達 (あまり見てないけど多分Wikiとかプロジェクト管理ツールとか)が使えるみたい。

Pricing/Plans | Assembla

それはもぅ速攻でユーザ登録してインポートしたり、チェックアウトしたりしてみました。
特に遅くもなく普通です。
試したのはたった15MB位のプロジェクトだからか、普段使っている会社のワークステーションに建てたローカルなSubversionよりも早い位。

これ、めっちゃいいですやん。

PublicなGoogle Codeでは無く、非公開なSuvbersion(またはGit)が使いたい方は勿論、バックアップ目的など色々使えて便利でしょう。

使い方によってはDropBox並に便利かもしませれん。

急場しのぎで間に合わせの古いPCに作ったSubversionサーバ のリポジトリを、別のちゃんとしたサーバに移動した時のメモです。
例によって、個人的なメモなので超不親切です。

移動元のサーバで

svnadmin dump /home/svn/repos > /home/myuser/repos.dmp
scp /home/myuser/repos.dmp myuser@dest_server:/home/myuser/

新しい(移動先の)サーバで

svnadmin create /home/svn/repos
svnadmin load /home/svn/repos < /home/myuser/repos.dmp

基本的に、これだけです。

あとは、認証の設定とかの内容を、忘れずにコピペする位です。

私の環境では、この2つのファイルの中身を一部新サーバのそれにコピーしました。

vi /home/svn/repos/conf/svnserve.conf

vi /home/svn/repos/conf/passwd

Subversionの最新バージョンは1.6.6らしいけど、壊れたサーバにあわせて1.4.2をインストールします。
2～3年前から更新とまっているような。

個人的なメモなので超不親切です。

Berkeley DB 4.5.20 をインストール

cd /usr/local/src
wget http://download.oracle.com/berkeley-db/db-4.5.20.tar.gz
tar zxfv db-4.5.20.tar.gz

cd /usr/local/src/db-4.5.20/build_unix/
../dist/configure
make
make install

ls /usr/local/BerkeleyDB.4.5

vi /etc/ld.so.conf
#--------------------------------------------------------------------
include /usr/local/BerkeleyDB.4.5/lib
#--------------------------------------------------------------------

/sbin/ldconfig

Subversion 1.4.2 をインストール

cd /usr/local/src
wget http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz

cd /usr/local/src
tar zxfv subversion-1.4.2.tar.gz
cd /usr/local/src/subversion-1.4.2

./configure --with-berkeley-db=/usr/local/BerkeleyDB.4.5

ここでエラーが発生。

	configure: error: APR-UTIL was installed independently,
	it won't be possible to use the specified Berkeley DB: /usr/local/BerkeleyDB.4.5

参考サイトを参考に、以前インストールしたApache2.2.4があったので、それを流用したらインストールできました。

cd /usr/local/src/subversion-1.4.2
cp -a ../httpd-2.2.4/srclib/{apr,apr-util} .
./configure --with-berkeley-db=/usr/local/BerkeleyDB.4.5
cd /usr/local/src/db-4.5.20/build_unix/
../dist/configure
make
make install

vi /etc/sysconfig/iptables
---------------------------------------------------------------------
# subversion
-A RH-Firewall-1-INPUT -s 192.168.0.0/16 -m state --state NEW -m tcp -p tcp --dport 3690 -j ACCEPT
---------------------------------------------------------------------
/etc/init.d/iptables restart

vi /home/svn/repos/conf/svnserve.conf
---------------------------------------------------------------------
[general]
anon-access = none
auth-access = write
password-db = passwd
realm = My First Repository
---------------------------------------------------------------------

vi /home/svn/repos/conf/passwd
	※適宜
---------------------------------------------------------------------
svnuser = pass
---------------------------------------------------------------------

vi /etc/rc.d/rc.local
---------------------------------------------------------------------
/usr/local/bin/svnserve -d -r /home/svn/repos &
---------------------------------------------------------------------

#壊れたPCから救出したHDDの /share/svn/repos のシンボリックリンクを作って終わり
chown -R nobody:dev /share/svn
ln -s /share/svn /home/svn

こんどちゃんと再構築しよう。

USBメモリでブータブルなGPartedがあると、何かと便利です。

サイトのドキュメントでは、Linux上でのLive on USBの作り方を説明していますが、作業はWindows機でも行えます。

200MB以上の容量のUSBメモリを用意し、FAT32でフォーマットする。

USBメモリをWindows機に接続する。(ドライブレターは仮にD:とする)

ここからSourceforgeのダウンロードページへとぶ。

gparted-live-0.4.6-1.zip をダウンロードする。

ダウンロードしたzipファイルを、USBメモリ(D:\)に解凍する。

D:\util\win32\makeboot.batを実行し、指示に従う。(ここでsyslinuxが実行され、USBがブータブルに変身します)

USBメモリによってはブータブルにならないものもあります。
私の場合USBメモリを2つ試して、1つ成功でした。