我有一个服务器pmaster-dev是一个puppet客户端（它的主人是pmaster ）。 服务器pmaster-dev本身充当几个客户的木偶大师。
当pmaster-dev与pmaster签入时，它将其事实caching到本地sqlite3数据库文件/var/lib/puppet/state/clientconfigs.sqlite 。 在每个后续的检查中， pmaster-dev都不会更新这个本地caching。 因此，它的事实总是陈旧的。 pmaster的其他客户端（包括pmaster本身）永远不会caching。
我们如何告诉它更新caching或禁用caching事实？ 为什么在pmaster的其他客户端不caching的时候caching？
我们在Debian挤压系统上运行2.7.18。
这是pmaster-dev的/etc/puppet/puppet.conf文件：
[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
在对Puppet Ruby源文件进行了一些挖掘之后，我将问题追踪到Puppetconfiguration文件部分出现混乱的问题。 这一切归结为“主”
总结 ：在扮演Puppet客户端和“主”环境的情况下，Puppet掌握了configuration文件parsing的问题。
详细信息 ：当puppet代理启动其中一件事情时，parsingconfiguration文件（通常是/etc/puppet/puppet.conf ）。
configuration文件被分解成若干部分，例如“[main]”，“[agent]”，“[master]”等。这些部分分别存储在parsingconfiguration文件生成的哈希中。 在我的情况下， pmaster-dev有这些部分：“内存”，“主”，“cli”和“代理”。
也可以是每个环境部分。 例如，如果有一个名为“stable201301”的环境，那么在configuration文件中可以有一个标题为“[stable201301]”的部分。
对于上述每个部分（在代码中称为“来源”），您将检查所有具有关联“挂钩”的设置。 如果在该部分中定义了钩子设置，则调用该设置的钩子。 一些具有挂钩的设置包括catalog_format，node_name_fact和storeconfigs。
其中一个比较有趣的设置是“async_storeconfigs”，它有一个挂钩来设置一个caching类。
回想一下，这些部分还可以包含每个环境的部分。 问题：如果木偶大师（当扮演木偶客户端）处于“主”环境中，该怎么办？
“[master]”部分的常用angular色是用于Puppet主控的设置。 但是如果木偶大师自己使用的是“主”环境，我们就有冲突。 特别是从configuration文件中加载“[master]”的“async_storeconfigs”设置。 由于Puppet master（作为Puppet客户端）处于“master”环境中，因此该设置会导致设置caching类，所以当puppet agent --test运行时，puppet客户端会查找caching的事实。
解决scheme（？） ：你可以确保一个Puppet主从不使用“主”环境。 一个更好的解决scheme是让客户端configurationparsing器不要看“[master]”部分（因为它只适用于Puppet主控器）。 更好的解决scheme是将客户端和主configuration文件完全分开。
似乎你对clientconfigs.sqlite实际上是什么感到困惑。 这个文件是Puppet的Stored Configuration机制的一部分。 这是由木偶大师维护的文件，而不是由客户维护。
它的创build由storeconfigs的[master]部分中的storeconfigs ， async_storeconfigs和db*参数puppet.conf 。 默认情况下（没有设置db*参数时）是使用SQLite适配器。
从你粘贴的configuration看来，你似乎已经configuration了master，通过Stomp代理将configuration存储在MySQL数据库中。 所以它似乎没有更新的SQLite数据库是由devise？
为什么这个数据库文件已经被创build是一个很好的问题。 我的假设是木偶大师在服务器的初始设置期间以不完整的configuration开始。