我が家で愛用する 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: #<EOFError: end of file reached>
これは Puppet クライアントを再起動すれば解決するが、あくまでも対処療法で、再発してしまう。それでも lenny は VPN サーバーの 1台だけだったので対応を後回しにしていたところ、ある出来事を機に lenny が計 3台に増え、「特別対応」 の手間が増えてしまった。これでは具合が悪いので、思い切って全 Puppet を比較的最近のバージョンまで上げることにした。
システムのコアとなる CentOS の Puppet は、EPEL で配布されている 0.25.5 を使うことにする。過去に epel リポジトリを手動で登録していなければ、次のようにするのが楽だ。
・epel リポジトリのパッケージをインストール # rpm -ivh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm ・確認 # rpm -q epel-release
念のため /etc/yum.repos.d/epel.repo の "epel" セクションで "eneble=1" になっていることを確認し、Puppet をアップデートする。
・アップデート前の確認 # rpm -q puppet puppet-0.22.4-1.el5 ・Puppet をアップデート # yum update puppet (または) # yum update puppet puppet-server ・確認 # rpm -q puppet (または) # rpm -qa | grep puppet | sort puppet-0.25.5-1.el5 puppet-server-0.25.5-1.el5
0.22.4 では、/etc/puppet 以下に puppetd.conf や puppetmasterd.conf 等、プログラムごとに設定ファイルが分離されていたのが、0.23.x 以降では puppet.conf に集約されている。旧来と同じ分離方式でも一応動くが非推奨と言うことなので、素直に 「今の」 やり方に切り替えた方がいいだろう。
上記作業で Puppet は新しくなるが、僕は設定ファイルの差分確認＆修正が面倒だったため、Puppet サーバーの autosign.conf と fileserver.conf、各マシンの namespaceauth.conf、/etc/sysconfig/puppet 以外は、全て削除して作り直した。「作り直した」 と言っても、内容はほぼデフォルトで全クライアント共通なので、大した手間ではない。
新しい Puppet サーバーとクライアント間で証明書の確認エラーが発生する場合は、該当マシンで Puppet クライアントをいったん止め、Puppet サーバーの $ssldir/ca/signed/<PUPPET_CLIENT>.pem と Puppet クライアントの $vardir (デフォルトで /var/lib/puppet) を削除して、改めて Puppet クライアントを起動する。
尚、僕は諸事情で Puppet サーバーの /etc/puppet/manifests をシンボリック・リンクにしていたが、0.25.5 ではここは本物のディレクトリでないとダメなようで、強制的にディレクトリに置換されてしまう。site.pp も同様だったので、やむを得ずリンク先のデータをコピーし、実パスとして存在する状態にした。
またかつて Puppet サーバー・マシンでは、puppetmasterd と puppetd で $ssldir として別の場所を指定していたが、今回 1つにまとまった puppet.conf 中で同様の設定をすると、クライアントが証明書を確認できなかった。puppetmasterd と puppetd の $ssldir を同じ場所すると正常動作するので、仕様変更だろうか。まァこれでも害はないので、$ssldir は同じ場所を使うことにした。
さて、今回の一大アップグレードの発端となった問題の lenny は、標準パッケージの 0.24.5-3 で 0.25.5 の Puppet サーバーと問題なく通信でき、原因不明の不具合も解消された。やはりこうでなくては。
