<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Natz&#039;s Digital 漂流記</title>
	<atom:link href="http://www.natzworks.com/digital/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.natzworks.com/digital</link>
	<description>Natz の PC/サーバー/デジタル機器に翻弄される日々</description>
	<lastBuildDate>Fri, 10 Sep 2010 16:11:59 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>CentOS = セントス？ セント・オーエス？</title>
		<link>http://www.natzworks.com/digital/2010/441.html</link>
		<comments>http://www.natzworks.com/digital/2010/441.html#comments</comments>
		<pubDate>Fri, 10 Sep 2010 15:08:05 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[CentOS]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=441</guid>
		<description><![CDATA[日付が変わって昨日 09/10 は、Open Source Conference 2010 Tokyo/Fall の 1日目に行って来た。いろいろと興味深い話が聞けて面白かったが、個人的に最高クラスの衝撃を受けたのが、あるセミナー講師の方が、CentOS を 「セントス」 と発音していたことだ。Red Hat Enterprise Linux クローンである CentOS の信頼性と人気は揺るぎないものがあり、僕の業務でも使用頻度は高く、我が家の主力サーバー用ディストリビューションでもある。僕はこの製品を 「セント・オーエス」 と発音していて、周辺では皆 「セント・オーエス」 と呼び、Wikipedia には 「セントオーエス」 と書いてある。
そう言う経緯から、他の読み方があるとは考えたことすらなかったところへ唐突に 「セントス」 と来れば、そのインパクトは推して知るべし。しかし衝撃を受けつつ、同時に 「(特に英語圏では) あり得るかも」 と言う感じもした。

そこで帰宅後に早速 Web で調べてみると、以前からあちこちで同様の議論が交わされていたことがわかった。ざっと眺めてみると、恐らく 「厳密に決まってるわけではないが、一応 『セントス』 が優勢で、『セント・オーエス』 でもまァよし」 と言う感じに見える。その根拠として示されていたのが、このやり取り。
なるほど。僕も今後は 「セントス」 に乗り換えてみよう。
ただ、周りが 「セント・オーエス」 と呼ぶ中で僕一人が突然 「セントス」 に乗り換えることで懸念されるのは、例えば 「脆弱性」 を 「きじゃくせい」 と読んでしまい、周囲は誰も突っ込まないが当然誤りに気付いていて、「漢字もロクに読めねーのか」 と密かに侮られてしまうのと同じ状況が発生することだ (かつて会議で 「イヤー、臨場感 (りんばかん) がスゴいね」 と発言した某氏には、誰も突っ込まなかった)。
僕自身では、"_" を正しく 「アンダースコア」 [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/441.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OpenLDAP のエラーで OS が起動しない</title>
		<link>http://www.natzworks.com/digital/2010/439.html</link>
		<comments>http://www.natzworks.com/digital/2010/439.html#comments</comments>
		<pubDate>Thu, 09 Sep 2010 13:29:44 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[CentOS]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[OpenLDAP]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=439</guid>
		<description><![CDATA[先日 OpenLDAP の Slave サーバーを担当する VMware ESXi 上の仮想マシン (以下 VM) の CentOS 5.5 で再起動をかけたところ、いつまで経っても起動が完了しない。妙だなと vSphere Client でコンソールを開いてみると、以下のエラー・メッセージと共に OS の起動プロセスが止まっていた。

Checking configuration files for slapd:  bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.


強制シャットダウンしたわけでもないし、OpenLDAP のデータが破損するような心当たりはなかったが、中途半端なところで OS の起動が止まっているせいで SSH ログインもできず (まだ sshd が起動していない)、どうにもならない。

仕方がないので、VM をリセットしてシングル・ユーザー・モードで OpenLDAP の自動起動を無効にし、とりあえず OS を普通に起動。改めて [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/439.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>VirtualBox: 仮想マシン終了後にホスト PC の [Ctrl] キーがロックされる</title>
		<link>http://www.natzworks.com/digital/2010/429.html</link>
		<comments>http://www.natzworks.com/digital/2010/429.html#comments</comments>
		<pubDate>Tue, 07 Sep 2010 14:33:38 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[VirtualBox]]></category>
		<category><![CDATA[アプリケーション]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=429</guid>
		<description><![CDATA[VirtualBox で仮想マシン (以下 VM) を起動して終了すると、たまにホスト PC (Windows 7 Ultimate x64) の [Ctrl] キーがロックされる (＝押下状態で固定される) ことがある。この [Ctrl] キー押しっぱなし状態になると、全てのキー入力が [Ctrl]+* のキー・アサインとみなされるせいか、文字入力もできなくなる。
キーボードで文字入力をしなくても、エクスプローラー等でマウスのクリックだけで複数オブジェクトを選択できてしまったり、「フォルダー オプション」 で ｢別のフォルダーを開くときに新しいウィンドウを作らない」 設定になっているにもかかわらず、フォルダーをダブル・クリックすると別ウィンドウでエクスプローラーが起動すると言った具合に、「[Ctrl] キー押しっぱなし」 で考えられるありとあらゆる症状を併発するので、すぐに気付くことが多い。

当初は VM のウィンドウを閉じて VM を強制終了したときに発生しやすいと考えていたが、VM を正しくシャットダウンしても起こるときは起こるため、終了方法はあまり関係なさそうだ。
まァ左 [Ctrl] キーを (1回ないし複数回) 押すだけで解消するので、深刻な問題ではないが、少々気持ち悪い。この現象は VirtualBox のかなり前のバージョンから発生していて、現時点の最新版 3.2.8 でも変化はなし。
]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/429.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OpenSolaris のユーザー・アカウントを OpenLDAP で管理</title>
		<link>http://www.natzworks.com/digital/2010/438.html</link>
		<comments>http://www.natzworks.com/digital/2010/438.html#comments</comments>
		<pubDate>Sat, 04 Sep 2010 22:22:45 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[OS]]></category>
		<category><![CDATA[OpenLDAP]]></category>
		<category><![CDATA[OpenSolaris]]></category>
		<category><![CDATA[Solaris]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=438</guid>
		<description><![CDATA[次世代 (と言っても Solaris 10 から BSD 系にも移植されて、既にそこそこ普及しているようだが) ファイル・システム ZFS に慣れるため、少し前から OpenSolaris 2009.06 をチマチマといじっている。ライセンス問題が横たわる Linux でも一応 FUSE 経由で ZFS は使えるものの、やはりパフォーマンスではネイティブ動作にやや劣るし、機能も一部制限されるとのこと。Linux にネイティブ移植される日を待ちながら、本場の ZFS で腕を磨いておくとしよう。
その OpenSolaris は VMware ESXi 上のテスト用仮想マシン (以下 VM) とは言え、我が家ではユーザー・アカウントを OpenLDAP で管理しているので、他の Linux と同様に LDAP クライアントとして設定したい。ところが最近の Linux では比較的簡単になったこの設定も、いろいろと勝手が違う OpenSolaris では少々手こずった。

ああだこうだと彷徨った様子を紹介しても仕方がないので、ズバリ結論を書いてしまうと、このページにある方法で上手く行った。最低限必要な作業は、以下の 3ステップ。


# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=DNname,dc=example,dc=com \
-a proxyPassword=password \
-a defaultSearchBase=dc=example,dc=com \
-a defaultServerList=192.168.xxx.xxx:389 [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/438.html/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>電源タップとケーブルを隠蔽</title>
		<link>http://www.natzworks.com/digital/2010/437.html</link>
		<comments>http://www.natzworks.com/digital/2010/437.html#comments</comments>
		<pubDate>Sun, 29 Aug 2010 10:08:30 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[PC 自作]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=437</guid>
		<description><![CDATA[先日、近所の雑貨屋で The CableBox なる商品を見かけ、衝動的に買ってみた。これは電源タップやケーブルを隠すための箱で、我が家のサーバー、PC、その他周辺機器類から伸びる大量のケーブルを隠蔽するのに、大小ある製品バリエーションのうち、デカい方がちょうどいいサイズだったからだ。
早速自宅の机の下を這い回っていた 6口の電源タップ 2本と大量のケーブルを押し込んでみると、非常にスッキリまとまった。煌々とオレンジに点灯し、部屋を暗くすると目障りだった電源タップの差込口の ON/OFF を個別に切り替えるスイッチも、完全に視界から消えて快適になった (12個のうち 9～10個が点灯していると、意外と明るくなる)。

さらに前述の製品サイトでもアピールされているように、隙間に溜まった埃が何かの拍子で発火する事故 (「トラッキング現象」 と言うらしい) のリスクを軽減できることは、常時稼動機器が多い我が家ではポイントが高い。ケーブル類が一まとめになったことで、掃除の際も楽になる。
まァ実際のところはただのプラスチックの箱だし、雑貨屋では定価 (&#165;3,980) で買ってしまったことも相まって、(価格とのバランスで) 何かこう釈然としないモヤモヤ感がないとは言わないが、効果は謳い文句どおり。デッド・スペースになりがちな電源タップ上にモノを置くこともできるので、興味がある方はぜひどうぞ。




]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/437.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Puppet: マニフェストを puppetrun で配信</title>
		<link>http://www.natzworks.com/digital/2010/435.html</link>
		<comments>http://www.natzworks.com/digital/2010/435.html#comments</comments>
		<pubDate>Wed, 25 Aug 2010 21:45:45 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=435</guid>
		<description><![CDATA[今まで我が家のサーバー管理自動化ツール Puppet で各ノードの設定ファイルであるマニフェストを配信する方法は、Puppet クライアント (puppetd) が好き勝手なタイミング (30分間隔) で Puppet サーバー (puppetmasterd) から取得するデフォルト方式だった。この方式の問題点は、管理ノード数が増えて来ると、各 Puppet クライアントの起動タイミングによっては Puppet サーバーへのアクセスが集中してしまうことだ。
Puppet サーバーは負荷が軽いわけではなく、我が家のささやかなスペックの仮想マシン (以下 VM) にとっては、意外と苦しい。しかも Puppet 経由で配信する設定やファイルの変更はそれほど緊急性が高くないことが多いので、全 Puppet クライアントが 30分おきに Puppet サーバーを見に来るのは、ハッキリ言って少々うるさい。Puppet サーバーの気持ちを代弁するなら、「そんなにしょっちゅう見に来ても、さっきと変わってねーよ」 と言ったところだろう。
そこで Puppet サーバーの負荷分散のため、マニフェストの配信を Puppet サーバーが Puppet クライアントに対して 「取りに来い」 と促す、puppetrun コマンド経由に切り替えた。Puppet クライアントが Puppet サーバーに勝手なアクセスをしないようにし、Puppet サーバー上で各ノードに対して 1台ずつ順番にマニフェストの参照をキックするスクリプトを任意のタイミングで走らせれば、アクセスを均等に散らすことができる。

切り替え手順は、以下の通り。

Puppet クライアントに起動オプションを追加。
Puppet サーバー及びクライアントに namespaceauth.conf を用意。
ファイア・ウォールで puppetrun 用ポートを開放。

完全 puppetrun 化に必要な Puppet クライアントの起動オプションは "--listen" と [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/435.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>openSUSE 11.3 で Facter 変数 lsbmajdistrelease を参照できない</title>
		<link>http://www.natzworks.com/digital/2010/431.html</link>
		<comments>http://www.natzworks.com/digital/2010/431.html#comments</comments>
		<pubDate>Thu, 12 Aug 2010 16:25:00 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[Puppet]]></category>
		<category><![CDATA[openSUSE]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=431</guid>
		<description><![CDATA[先日唐突に 「最新の openSUSE を触ってみるか」 と思い付いて、07/15 にリリースされたばかりの openSUSE 11.3 を VirtualBox 上でインストールしてみた。openSUSE はまだ名称が SUSE Linux だった時代に、我が家の自宅サーバー環境のメインとして採用していた思い入れのあるディストリビューションで、個人的には (runlevel 3 の) コンソールの背景に画像が表示される半透明風の表現がお気に入り。この表現はいつから始まったか知らないが、SUSE Linux 9.x では既に導入されていて、当時は SSH 経由でログインしたときにこの画面で操作できないことを、残念に思ったものだ。

runlevel 3 のコンソール
さて、その openSUSE 11.3 マシンをサーバー管理自動化ツール Puppet の管理下に置こうとしたところ、Facter 変数 lsbmajdistrelease を参照できなかった。lsbmajdistrelease は、例えば CentOS の 3.x では "3"、4.x では "4"、5.x では "5" のようにディストリビューションのメジャー・バージョンが格納される変数で、我が家の Puppet でマニフェストの条件分岐の要として活用しているため、使えないと具合が悪い。

まず以下のパッケージが存在しなければ、YaST でインストールする。

facter
lsb
lsb-release

しかしこれら (と依存関係にある全て) のパッケージがインストールされた状態で


$ facter


と実行しても、変数 lsbmajdistrelease が表示されない。そこで /usr/lib/ruby/vendor_ruby/1.8/facter/lsbmajdistrelease.rb (CentOS [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/431.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>同名ソフトの怪</title>
		<link>http://www.natzworks.com/digital/2010/430.html</link>
		<comments>http://www.natzworks.com/digital/2010/430.html#comments</comments>
		<pubDate>Fri, 06 Aug 2010 13:21:47 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[雑記]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=430</guid>
		<description><![CDATA[先日とある業務で、別会社によって BiND for WebLiFE で制作された某 Web サイトの一部に、メール・フォーム等の機能追加＆一部修正をした。既存部分と連動しなくても (＝BiND for WebLiFE 上のデータ管理から外れても) 構わないと言うことで、普段通り Eclipse + Dreamweaver で作業させてもらえたので助かった。
さてこの BiND for WebLiFE (大文字小文字が入り乱れていてタイプしづらい) のバージョン 1.0 が 2007年にリリースされたときは、Web 系雑誌等で 「革新的 Web 制作ツール」 と言った感じで紹介されていた。当時僕は 「Web サイトのプロトタイプ制作の省力化に使えるかも」 と期待して触ってみたものの、他の編集ツールやテキスト・エディター等の力技が入ると破綻しやすく (＝ソースを直接編集するような使い方は想定外のはず)、全ての作業を同ソフト上で完結させなければいけなそうな点がスタイルに合わなかったため、採用を見送った経緯がある。

まァその辺の事情については、バージョンを重ねた現在では解決策が編み出されていたり、実は最初からスマートな方法があったかもしれないのであまり触れないが、それにしてもこの製品名は、理解に苦しむところだ。世界的に有名な先発ソフトがあるのに、なぜ同じ名前を使うのか。他に選択肢がいくらでもある中で、敢えて同じ名前を付ける理由は何なのか。
例えば僕が "postFIX pro" とか "SAMBA!! for your life" なんて名前で有償のメディア・プレイヤーを開発したとして、これが変に出来がよくて有名になってしまい、サーバー構築や管理とは無縁の一般ユーザーが 「音楽聴くなら断然 SAMBA!! だよね」 と言い放つような事態が発生したら、どうだろうか？ 思わずニヤけてしまうほどの売上を計上できても、開発者のモラル的にはアウトだろう。世の多くの IT 技術者から白眼視されることは、容易に想像がつく。
「Case sensitive なら別名だ」 「先発にはない文字列を付加してるから別名だ」 とでも主張するなら、例え法的な問題には発展しなくても、この手の命名に関しては詭弁だと思う。後発側が 「イヤ、あっちとは関係ありません」 「名前が似てるけど別物です」 と主張し続ける茨の道を自ら歩むのは勝手だが、先発側にもそれを強いる可能性や、抗議等に費やす様々な労力については、どう考えているのだろうか？ [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/430.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CentOS 5.5 でも VMware Server 2.0.x の仮想マシンが落ちる</title>
		<link>http://www.natzworks.com/digital/2010/428.html</link>
		<comments>http://www.natzworks.com/digital/2010/428.html#comments</comments>
		<pubDate>Mon, 26 Jul 2010 14:11:55 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[VMware Server]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=428</guid>
		<description><![CDATA[05/14 に CentOS 5.5 がリリースされ、既に 2ヶ月が経過した。我が家の仮想マシン (以下 VM) の CentOS 5.x は比較的早い段階で 5.5 にバージョンアップしているが、VMware Server 2.0.2 が稼動する VM 親機の CentOS は例の glibc 問題が依然として横たわっているため、glibc を 2.5-34.el5_3.1 にバージョンダウンした 5.4 のまま放置していた。
しかし永久にこのまま放置するわけにもいかんだろ、と言うことで、先日ついに VM 親機で yum update を敢行した。普段 glibc と nscd は yum.conf で exclude 指定してあるが、そのまま yum update してはせっかくの blog のネタがなくなるので、敢えて指定を外し、ひとまず 「普通の 5.5」 にバージョンアップしている。

更新されるパッケージ数が多く、多少時間がかかったが、バージョンアップ自体は問題なく完了。OS を再起動後に vmware-config.pl を実行して VMware Server を起動し、テスト用の [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/428.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DRBD リソース・サイズを拡張</title>
		<link>http://www.natzworks.com/digital/2010/425.html</link>
		<comments>http://www.natzworks.com/digital/2010/425.html#comments</comments>
		<pubDate>Sun, 11 Jul 2010 14:25:46 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[DRBD]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/2010/425.html</guid>
		<description><![CDATA[先日、我が家で稼動するメール・サーバーのスプール領域を拡張した。このメール・サーバーはDRBD + Heartbeat による高可用性クラスター構成を採る仮想マシン 2台のペアで、スプール領域は DRBD の下地に LVM を利用している。
ディスク領域の拡張・縮小に LVM が威力を発揮するのは言うまでもないが、その上に DRBD が乗った場合は、DRBD リソースのサイズも変更しなければいけない。その作業で少々混乱したので (情報量少ない？)、記録に残しておく。

まず最近リニューアルされた日本語サイトの ユーザーズ・ガイド を見ると、DRBD リソースをオンラインで拡張する際の条件として、次のように書かれている。


影響を受けるリソースの下位デバイスが、 LVMやEVMSなどの論理ボリューム管理サブシステムによって管理されている。
リソースの接続状態が Connected になっている。


この条件を満たしていれば、ユーザーズ・ガイドの記述どおりにオンラインで拡張が可能だ。例えばボリューム・グループ vg01 内の論理ボリューム test01 を利用した DRBD リソース r0 (resource: r0, device: /dev/drbd0, meta-disk: 任意, disk: /dev/vg01/test01) を 1GB 拡張する場合は、次のようにする。


・LV を拡張 (Primary &#038; Secondary)
# lvextend -L +1G /dev/vg01/test01

・DRBD リソースを拡張 (Primary)
# drbdadm resize r0

・ファイル・システムを拡張 (Primary) (※ ファイル・システムが [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/425.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
