对于那些已经在运行配置管理工具的人来说，这可能是一个简单的问题。诸如 Puppet 或 Chef 之类的配置管理工具是否是使已安装的软件包保持最新的正确方法？
假设我运行了许多服务器，主要基于 Debian 和 Ubuntu。当安全更新或错误修复出现时，配置管理工具是否可以更轻松地更新从存储库安装的包？
我目前运行“无人值守升级”以让系统自动安装安全更新，但我仍然需要连接到服务器并aptitude update && aptitude safe-upgrade经常运行。当然，服务器越多，这就会变得无聊、乏味且容易出错。
诸如 Puppet 或 Chef 之类的工具是否是使安装的软件包保持最新的正确方法？你们中有人使用这些工具来避免aptitude在 15 台服务器上手动运行或等效吗？我很确定这些问题的答案是“是的，当然！”
但是在哪里可以找到有关此特定用例的更多信息？我还没有时间深入研究 Puppet 或 Chef，示例食谱或课程仅展示了安装特定软件包（例如 ssh）的或多或少的琐碎示例。除了官方文档之外，您还有其他资源可以推荐吗（当然，一旦我知道哪些工具适合我，我就会研究文档）。
我有一个客户，由于他们对 GDPR 的解释，现在要求我们每 90 天更改一次密码。对于我们为他们开发的基于 Web 的系统来说，这很好，因为我们可以实施这些规则。但它们也要求我们更改用于访问服务器的 SSH 密钥的密码，这并不好。
如果没有，我们可以使用任何工具来处理这个问题吗？我在想：
一种。创建新密钥。
湾 将所有公钥分发到现有服务器。
C。删除现有的公钥。
d. 存档旧私钥。
我已经在这里阅读了一些关于 Puppet 的帖子，但据我所知，他们的目的只是解决在服务器之间分发公钥而不是每 n 天创建新密钥的问题？我应该进一步研究 Puppet 吗？
在密码保留和 ssh 密钥方面，社区标准是什么？你怎么做呢？
我试图找出使用来自本地源 deb 文件的 puppet 更新/升级 deb 包的正确方法。我当前的配置看起来像这样......
class adobe-air-2-0-4 {
file { "/opt/air-debs":
ensure => directory
}
file { "/opt/air-debs/adobeair-2.0.4.deb":
owner => root,
group => root,
mode => 644,
ensure => present,
source => "puppet://puppet/adobe-air-2-0-4/adobeair-2.0.4.deb"
}
package { "adobeair":
provider => dpkg,
ensure => installed,
source => "/opt/air-debs/adobeair-2.0.4.deb"
}
}
我首先将 deb 文件复制到客户端计算机，然后使用“package”，提供程序设置为“dpkg”。这有效，我安装了正确的版本。
我的问题是将来更新此软件包的正确方法是什么。我可以简单地更改源文件，puppet 会知道它是一个不同的版本并更新这个包吗？puppet 如何确定它安装的软件包版本与源 deb 文件的版本？
我对 puppet 还很陌生，所以如果您对我现有的配置有任何改进建议，我们将不胜感激。
背景：
我终于留出一些时间加入 21 世纪，看看 Puppet。
就目前而言，我们在办公室内部保存的存储库中对所有服务器配置进行版本控制。当需要进行更新时，更改会被检回存储库并手动推送到有问题的机器上。这通常意味着 SFTP 到远程机器，然后将文件从 shell 移动到具有相关权限的位置。
所以我希望 Puppet 将成为我们已有的简单而惊人的扩展。
现在我考虑我们目前必须合理安全的流程。假设我们的内部网络总是比我们数据中心的公共网络相对更安全。
过程总是一种方式。变化从安全的环境到不安全的环境，而不会反过来。
主存储在最安全的地方。通过窃取配置或发送恶意修改的危害风险大大降低。
题：
根据我对 Puppet 服务器/客户端模型的理解，客户端直接从服务器轮询和拉取更新。流量是 SSL 包装的，因此不能被拦截或欺骗。但它与我们目前所做的不同，因为 Puppet 服务器 [s] 需要托管在公共位置。要么集中，要么针对我们维护的每个数据中心站点。
所以我想知道：
我是否对从推到拉的变化感到不必要的偏执？
我是否对在公共网络上集中存储所有这些信息感到不必要的偏执？
其他人如何维护多个网络——每个站点都有单独的服务器？
09 年 7 月 30 日更新：
我想我的另一个大问题是必须信任一台机器。puppetmaster(s) 将被防火墙保护，安全等。但即便如此，任何具有侦听服务的公共机器都有一定规模的攻击面。
据推测，如果 master 有权更新任何一个 puppet 客户端上的任何文件，那么它的妥协最终会导致其所有客户端的妥协。可以说是“国王到王国”。
这个假设正确吗？
有什么办法可以缓解吗？
有没有办法强制人偶先做某些事情？例如，在安装任何软件包之前，我需要它在所有服务器上安装 RPM 以添加 yum 存储库（IUS 社区）。
Puppet需要被管理的客户端（puppet）和服务器（puppetmaster）之间的证书。您可以在客户端手动运行，然后进入服务器对证书进行签名，但是如何为集群/云机器自动执行此过程？
更成熟的配置管理 (CM) 系统（如 Puppet 和 Chef）使用基于拉取的方法：客户端定期轮询集中主节点以获取更新。其中一些也提供了一种无主方法（因此，基于推送），但声明它“不适用于生产”（Saltstack）或“可扩展性较差”（Puppet）。我所知道的唯一一个从一开始就基于推送的系统是亚军 Ansible。
基于拉的系统的具体可扩展性优势是什么？为什么据说添加更多 pull-masters 比 push-agents 更容易？
例如，agiletesting.blogspot.nl写道：
在“拉”系统中，客户端相互独立地联系服务器，因此整个系统比“推”系统更具可扩展性
另一方面，Rackspace 证明他们可以使用基于推送的模型处理 15K 系统。
我们发誓使用拉式方法来维护基础架构，使用 SUP、CVSup、rsync 服务器或 cfengine 等工具。不是将更改推送给客户端，每个单独的客户端计算机都需要负责在启动时轮询黄金服务器，并在之后定期轮询，以保持自己的 rev 级别。在采用这个观点之前，我们开发了大量基于 ssh、rsh、rcp 和 rdist 的基于推送的脚本。我们在 r-commands（或 ssh）中发现的问题是：当您运行基于 r-command 的脚本将更改推送到您的目标机器时，很可能如果您有 30 多个目标主机，其中一个将在任何给定的时间下来。维护委托机器的列表变成了一场噩梦。在编写代码来纠正这个问题的过程中，你最终会得到精心设计的包装器代码来处理：死主机超时；记录和重试死主机；分叉并运行并行作业以尝试在合理的时间内访问许多主机；最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们为实现基于 r-command 的复制而遇到的麻烦之后，我们发现它只是不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。分叉并运行并行作业以尝试在合理的时间内访问许多主机；最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们实现基于 r-command 的复制遇到麻烦之后，我们发现它不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。分叉并运行并行作业以尝试在合理的时间内访问许多主机；最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们为实现基于 r-command 的复制而遇到的麻烦之后，我们发现它只是不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们实现基于 r-command 的复制遇到麻烦之后，我们发现它不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们实现基于 r-command …
如果通过 puppet 从主存储库将新版本的配置文件下载到托管服务器之一，我如何确保重新启动相关服务。
典型场景 - 假设有新的 munin 或 apache 配置。puppet 客户端发现它，覆盖本地文件......以及...... - 如何确保服务重新启动/重新加载？
多谢！
我似乎在理解如何使其工作时遇到了一些问题。我有一台正在工作的办公室 NAT 后面正在建造的新服务器，它的反向 dns 映射到office.mydomain.com，但我希望这台机器是ns2.mydomain.com为了傀儡。
node.pp 片段：
node 'ns2.mydomain.com' inherits basenode {
info('ns2.mydomain.com')
}
node 'office.mydomain.com' inherits basenode {
info('office.mydomain.com')
}
我在客户端上的“puppet.conf”：
[main]
#was node_name=ns2.mydomain.com
#was fqdn=ns2.mydomain.com
certname=ns2.mydomain.com
node_name=cert
我在服务器上的系统日志报告：
Sep 16 22:59:12 support puppetmasterd[2800]: Host is missing hostname and/or domain: office.mydomain.com
Sep 16 22:59:12 support puppetmasterd[2800]: (Scope(Node[office.mydomain.com])) office.mydomain.com
Sep 16 22:59:12 support puppetmasterd[2800]: Compiled catalog for office.mydomain.com in 0.03 seconds
Sep 16 22:59:12 support puppetmasterd[2800]: Caching catalog for ns2.mydomain.com
我怎样才能让它在ns2.mydomain.com不做这样的事情的情况下获取配置：
node 'ns2.mydomain.com' inherits …我正在尝试在 puppet 中编写一个函数，fail如果传递的目录路径不存在，它将执行。
if File["/some/path"]始终返回true，并且if defined(File["/some/path"])只有在puppet 中定义了资源时才返回true，而不管它是否实际存在。
有没有办法用一个简单的if语句来做到这一点？
谢谢