web-dev-qa-db-ja.com

Puppetクライアントのキャッシュはあるがローカルファクトは更新されていない

私はパペットクライアントであるサーバーpmaster-devを持っています（そのマスターはpmasterです）。サーバーpmaster-dev自体は、複数のクライアントのパペットマスターとして機能します。

pmaster-devがpmasterでチェックインすると、その事実がローカルのsqlite3データベースファイルにキャッシュされます/var/lib/puppet/state/clientconfigs.sqlite。その後のチェックインごとにpmaster-devこのローカルキャッシュを更新することはありません。したがって、その事実は常に古くなっています。 pmaster（pmaster自体を含む）の他のクライアントは決してキャッシュしません。

キャッシュを更新するか、ファクトのキャッシュを無効にするように指示するにはどうすればよいですか？ pmasterの他のクライアントがキャッシュしていないのに、なぜキャッシュしているのですか？

Debian squeezeシステムで2.7.18を実行しています。

これが/etc/puppet/puppet.confファイルpmaster-dev：

[agent]
server = pmaster.example.org
environment = master
configtimeout = 300

logdir = /var/log/puppet
vardir = /var/lib/puppet
ssldir = /etc/puppet/ssl
rundir = /var/run/puppet

ca_server = puppetca.example.org
ca_port = 8141

graph = true
report = true
pluginsync = true

classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
diff_args = '-u'
show_diff = true


[master]
certname = pmaster-dev.example.org
syslogfacility = local2

logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run/puppet
ssldir = /srv/puppetmaster/ssl

reports = tagmail,lastcheck,logcache
manifest = /srv/puppet/$environment/manifests/site.pp
graph = true
modulepath = /srv/puppet/$environment/modules:/srv/puppet/$environment/services:/srv/puppet/$environment/clients
cacrl = /srv/puppetmaster/ssl/crl.pem
ca = false

manifestdir = /srv/puppet/$environment/manifests
queue_source = stomp://pupqueue-dev.example.org:61613/
async_storeconfigs = true
storeconfigs = false
dbadapter = mysql
dbuser = puppet
dbpassword = secret
dbserver = pupqueue-dev.example.org
dbname = puppet

ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
puppetpuppetmaster
3
user35042

Puppet Rubyソースファイルを少し掘り下げた後、Puppet構成ファイルのセクションが統合されているというバグに問題を追跡しました。すべては「マスター」というWordに要約されます。

概要：Puppetクライアントとして動作し、「マスター」環境にあるPuppetマスターは、構成ファイルの解析で問題を引き起こします。

詳細：パペットエージェントが実行することの1つを開始すると、構成ファイルが解析されます（通常は/etc/puppet/puppet.conf）。

構成ファイルは、「[main]」、「[agent]」、「[master]」などのセクションに分割されます。これらの各セクションは、構成ファイルの解析から生成されたハッシュに個別に保存されます。私の場合、pmaster-devには、「メモリ」、「マスター」、「cli」、「エージェント」のセクションがあります。

環境ごとのセクションもあります。たとえば、「stable201301」という環境がある場合、構成ファイルに「[stable201301]」という見出しのセクションがある可能性があります。

上記の各セクション（コードでは「ソース」と呼ばれます）について、「フック」に関連付けられているすべての設定を調べます。そのセクションでフック付きの設定が定義されている場合は、その設定のフックを呼び出します。フックを持つ設定には、catalog_format、node_name_fact、storeconfigsなどがあります。

より興味深い設定の1つは、キャッシュクラスを設定するフックを持つ「async_storeconfigs」です。

セクションには、環境ごとのセクションも含めることができることを思い出してください。問題：Puppetマスター（Puppetクライアントとして機能している場合）が「マスター」環境にある場合はどうなりますか？

「[master]」セクションの通常の役割は、Puppetマスターの設定です。しかし、Puppetマスター自体が「マスター」環境を使用している場合、競合が発生します。特に、「[master]」の「async_storeconfigs」設定は構成ファイルからロードされます。 Puppetマスター（Puppetクライアントとして）は「マスター」環境にあるため、この設定によりキャッシュクラスが設定され、puppet agent --testが実行され、puppetクライアントがキャッシュされたファクトを探します。

Solution（？）：Puppetマスターが「マスター」環境を使用したことがないことを確認できます。より良い解決策は、クライアント構成パーサーに「[master]」セクションを表示させないことです（これはPuppetマスターにのみ適用されるため）。さらに優れたソリューションは、クライアントとマスターの構成ファイルを完全に分離することです。

1
user35042

clientconfigs.sqliteが実際に何であるかについて混乱しているようです。このファイルは、Puppetの 保存された構成 メカニズムの一部です。これは、クライアントではなく、Puppet Masterによって維持されるファイルです。

その作成は、async_storeconfigsのdb*セクションにあるstoreconfigs、[master]、およびpuppet.confパラメーターによって制御されます。デフォルト（db*パラメーターが設定されていない場合）は、SQLiteアダプターを使用します。

貼り付けた構成から、Stompブローカーを介してMySQLデータベース内に構成を保存するようにマスターを構成したようです。 SQLiteデータベースを更新しないのは設計によるものですか？

そもそもなぜこのデータベースファイルが作成されたのかは良い質問です。私の仮説は、PuppetMasterがサーバーの初期セットアップ中に不完全な構成で開始したというものです。

0
Damien Tournoud