<?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 漂流記 &#187; Puppet</title>
	<atom:link href="http://www.natzworks.com/digital/servers/puppet/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.natzworks.com/digital</link>
	<description>Natz の PC/サーバー/デジタル機器に翻弄される日々</description>
	<lastBuildDate>Wed, 28 Dec 2011 05:33:35 +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>Puppet 0.22.4 → 0.25.5 アップグレード</title>
		<link>http://www.natzworks.com/digital/2010/449.html</link>
		<comments>http://www.natzworks.com/digital/2010/449.html#comments</comments>
		<pubDate>Fri, 15 Oct 2010 16:06:21 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[CentOS]]></category>
		<category><![CDATA[Debian/GNU Linux]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=449</guid>
		<description><![CDATA[我が家で愛用する Puppet は CentOS の dag リポジトリにある 0.22.4-1 で、Debian GNU/Linux 5.0 (以下 lenny) でもこれに合わせ、標準の 0.24.5-3 ではなく、0.22.4 をムリヤリ突っ込んで運用していた。
lenny で敢えて古いバージョンを採用したのは、0.24.5 の Puppet クライアントと CentOS で動く 0.22.4 の Puppet サーバーが上手く連動できなかったため。lenny の Puppet を 0.22.4 に落とすと、0.22.4 の Puppet サーバーと通信できる (＝Puppet 上のファイル・サーバーからファイルを取得できる) ようにはなったが、たまに以下のエラーを発して puppetrun に反応しなくなることがあり、密かな悩みの種になっていた。

Could not call puppetmaster.freshness: #&#60;EOFError: end of file reached&#62;


これは Puppet クライアントを再起動すれば解決するが、あくまでも対処療法で、再発してしまう。それでも lenny は VPN サーバーの 1台だけだったので対応を後回しにしていたところ、ある出来事を機に [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/449.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Puppet: puppetrun を有効にした puppetd が起動しない</title>
		<link>http://www.natzworks.com/digital/2010/436.html</link>
		<comments>http://www.natzworks.com/digital/2010/436.html#comments</comments>
		<pubDate>Sat, 11 Sep 2010 15:56:42 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/?p=436</guid>
		<description><![CDATA[サーバー管理自動化ツール Puppet のマニフェスト配信を、Puppet クライアント (puppetd) が Puppet サーバー (puppetmasterd) から能動的に取得するデフォルト方式から、Puppet サーバーが Puppet クライアントに対して puppetrun コマンドで 「取りに来い」 と促さない限り何のアクションもしない受動式に切り替えたのは、既報の通り。
マニフェスト配信方式の切り替え自体は特に困ることもなくすんなり完了したが、しばらく運用を続けているうちに、ある仮想マシン (以下 VM) の Puppet クライアントが反応しないことに気付いた。VM 上で Puppet クライアントは動作しているにもかかわらず、Puppet サーバーからの puppetrun に反応しないのだ。この状態で Puppet クライアントを restart させると起動に失敗し (＝起動したように見えるが、すぐに死ぬ)、VM 自体を再起動させると、Puppet クライアントは普通に起動する。
妙だなとログファイルの /var/log/puppet/http.log を見ると、次のようなログが記録されていた。

INFO  WEBrick 1.3.1
INFO  ruby 1.8.5 (2006-08-25) [i386-linux]
WARN  TCPServer Error: Address already in use - bind(2)



最初は "Address [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/436.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 サーバー及びクライアントのバージョンは 0.22.4)。

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

完全 puppetrun 化に必要な Puppet [...]]]></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>CentOS 5.4, Debian 5.0: Facter 変数 lsb* が参照できない</title>
		<link>http://www.natzworks.com/digital/entries/2010/000252.html</link>
		<comments>http://www.natzworks.com/digital/entries/2010/000252.html#comments</comments>
		<pubDate>Thu, 04 Feb 2010 22:03:29 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[CentOS]]></category>
		<category><![CDATA[Debian/GNU Linux]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/210.html</guid>
		<description><![CDATA[先日より多くの変数が利用できると言うことで Ruby ライブラリ Facter のバージョンを上げたが、我が家で稼働する 2台の仮想マシン (以下 VM) で、lsb* で始まる全ての変数が参照できていなかった。特に lsbmajdistrelease はアップグレードの目的の一つでもあったので、使えないのは困る。
lsb* が参照できない VM は、CentOS 5.4 と Debian/GNU Linux 5.0 が各 1台ずつ。実機を含む他のマシンでは問題ないので、どうせ何かのパッケージが足りないんだろうと、他の VM と rpm -qa &#124; sort を diff してみると、あっさり見つかった。

必要なパッケージは、以下の通り。

CentOS 5.4: redhat-lsb
Debian GNU/Linux 5.0: lsb-base, lsb-core, lsb-release

普段意識することはあまりないが、これも LSB (Linux Standard Base) プロジェクトの成果か。
]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2010/000252.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CentOS 5.4: Facter 1.3.7 → 1.5.7 アップグレード</title>
		<link>http://www.natzworks.com/digital/entries/2010/000247.html</link>
		<comments>http://www.natzworks.com/digital/entries/2010/000247.html#comments</comments>
		<pubDate>Thu, 28 Jan 2010 07:37:43 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[CentOS]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/206.html</guid>
		<description><![CDATA[CentOS で採用されるパッケージは、安定度重視の枯れたバージョンであることが多い。システム管理自動化ツール Puppet で利用する Ruby ライブラリ の Facter も、現時点での最新版 1.5.7 に対し、CentOS 5.4 のデフォルト・パッケージは 1.3.7 だ。
Facter 1.3.7 でも Puppet は問題なく動くが、1.5.7 では 1.3.7 にはない Facter 変数、例えばディストリビューションのメジャーバージョンを表す lsbmajdistrelease や、仮想化環境を表す virtual 等が追加されている (1.5.7 での Facter 関数一覧は、このサイトが参考になる)。Puppet のマニフェスト管理効率化はもちろん、自作スクリプト等でも参照可能な変数は多いほど便利なので、CentOS 5.4 の Facter を 1.5.7 に入れ替えることにした。

Facter 1.5.7 の RPM は検索すればいくつか見つかるが、せっかくソースの tar ボールに Red Hat 用の spec ファイルが含まれているので、自作する。
まず現時点の最新版、1.5.7 の tar ボールをここからダウンロード。展開後、デフォルトでバージョンが "1.5.5" となっているのを修正したり、生成されるパッケージ名をわかりやすくするため、spec [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2010/000247.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Debian GNU/Linux 5.0 に Puppet 0.22.4 をインストール</title>
		<link>http://www.natzworks.com/digital/entries/2010/000246.html</link>
		<comments>http://www.natzworks.com/digital/entries/2010/000246.html#comments</comments>
		<pubDate>Sun, 24 Jan 2010 02:58:08 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[Debian/GNU Linux]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/205.html</guid>
		<description><![CDATA[Debian GNU/Linux 5.0 (以下 lenny) にシステム管理自動化ツール Puppet をインストールするには、aptitude 一発で片付けるのが楽だ。しかし我が家のように Puppet サーバーが CentOS 5.x で稼働している環境に lenny を Puppet クライアントとして組み入れようとすると、問題が発生する。
CentOS 5.x で Puppet サーバーとして稼働する Puppet のバージョンは、DAG リポジトリからインストールした 0.22.4。一方 lenny の Puppet は 0.24.5-3 で、これをそのまま起動すると、ログファイルに
Failed to retrieve current state of resource: Cannot currently copy links Could not describe /～
と言うエラーが記録され、ファイルサーバー機能経由でファイルをコピーできない。クライアント側の設定ファイルに問題はなさそうだし、Puppet サーバー上のマニフェストも読めているが、ファイルのコピーに失敗してしまうのだ。
しばらく足掻いてみたが上手く行かないので、試行錯誤中に発見した 「Puppet のサーバーとクライアントでバージョンが違うと具合が悪い」と言う話を信じ、lenny の Puppet を 0.22.4 にダウングレードすることにした。我が家の lenny [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2010/000246.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CentOS 3.9 に Puppet 0.22.4 をインストール</title>
		<link>http://www.natzworks.com/digital/entries/2010/000243.html</link>
		<comments>http://www.natzworks.com/digital/entries/2010/000243.html#comments</comments>
		<pubDate>Wed, 06 Jan 2010 00:05:29 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[CentOS]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[OS]]></category>
		<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/202.html</guid>
		<description><![CDATA[メインの開発環境を CentOS 5 にして随分経つが、故あって CentOS 3 で自作 Web アプリケーションの動作検証をする必要が生じたため、CentOS 3.x 系の最新バージョン 3.9 の環境を仮想マシンで構築した。Wikipedia の記事によると、CentOS 3 の初リリースは 2004年 3月で、メンテナンス更新期限は 2010年 10月までとなっている。これだけ長期に渡ってメンテナンスが継続されるのは、エンタープライズ向けディストリビューションの利点だ。
さて、CentOS 3 で具体的に何をするかはどうでもいいとして、我が家では UNIX 系 OS の管理を Puppet で極力自動化することにしている。しかし初期設定が終わった CentOS 3.9 にも Puppet をインストールしようとしたところで、問題が発生した。Puppet のソース RPM は DAG リポジトリで提供されているものの、CentOS 3 標準の Ruby が 1.6.8 と古く、Puppet の動作条件 "Ruby &#62;= 1.8.1" に引っかかるのだ。
CentOS 4 以降なら (DAG がリポジトリに登録してあれば) yum で一発だし、Debian [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2010/000243.html/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Puppet 0.22 インストール</title>
		<link>http://www.natzworks.com/digital/entries/2009/000210.html</link>
		<comments>http://www.natzworks.com/digital/entries/2009/000210.html#comments</comments>
		<pubDate>Mon, 07 Sep 2009 06:36:29 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[Puppet]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/175.html</guid>
		<description><![CDATA[複数台のサーバーを運用する場合、各種設定ファイルやパッケージの状態を管理するのに、オープンソースのシステム管理自動化ツール Puppet は非常に便利だ。サーバーの台数が少なければ手作業でも何とかなるが、ある程度の規模になると、効率的なシステム管理には、部分的にでも管理を自動化するツールが必須になって来る。
CentOS が中心の我が家のサーバー群もかつては手作業で状態を管理していたが、数ヶ月前に Puppet を導入してからは、サーバー管理の自動化の恩恵に与っている。ファイルをコピーすると言った単純な操作だけでなく、クラスやテンプレートを活用して、OS や用途ごとにパッケージの状態等まで管理できるのが非常に便利だ。
しかしこの便利な Puppet
も、CentOS に導入時する際にはちょっとした罠が仕掛けられている。新ファイルサーバー構築中にこの罠が再現して懐かしい気分になったので、エントリーに残しておくことにする。初めて
Puppet の導入を試みた時は、ここでハマって悩んだものだ。出だしでつまづくと、実に萎える。

CentOS の場合はこちらのサイトで詳しく解説されているように yum でリポジトリからインストールできて便利なのだが、僕の環境の問題なのかインストーラーに不備があるのか、インストール後に Puppet を起動しても、以下のようなエラーを吐いて正常に起動しない。

Starting puppet: /usr/lib/ruby/site_ruby/1.8/puppet.rb:3:in `require': no such file to load -- facter (LoadError)
        from /usr/lib/ruby/site_ruby/1.8/puppet.rb:3
        from /usr/sbin/puppetd:157:in `require'
        from /usr/sbin/puppetd:157
問題の puppet.rb の 3行目を見ると facter のロードに失敗しているようで、ではロードに失敗していない 2行目のsingleton はどこにあるかと find してみると、/usr/lib/ruby/1.8/singleton.rb にある。と言うことは恐らく facter.rb と言うファイルもその近所にあるべきなのに存在しないか、マズい場所にあるのかなと再び find すると、/facter.rb と /facter ディレクトリが見つかる。
要するに /usr/lib/ruby/1.8 以下にあるべき facter パッケージの関連ファイルが "/" [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2009/000210.html/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

