我正在使用 Vagrant 来快速启动一些初始 Puppet 配置，并且对如何在 puppet 执行工作流中包含/运行多个清单（不仅仅是 site.pp）而不将额外的清单制作成模块并以这种方式包含它们感到困惑。
在我将 Vagrant 指向的 puppet manifests 目录中（见下文），我有两个要执行的清单：site.pp 和 hierasetup.pp。
config.vm.provision "puppet" do |puppet|
puppet.manifests_path = "puppet_files/manifests"
puppet.module_path = "puppet_files/modules"
puppet.manifest_file = "site.pp"
puppet.options = "--verbose --debug"
end
目前我让 site.pp 成为调用 hierasetup.pp 的清单。我的 site.pp 看起来像这样：
File {
owner => 'root',
group => 'root',
mode => '0644',
}
import "hierasetup.pp"
include jboss
但是我收到关于弃用“导入”的错误：
警告：在 /tmp/vagrant-puppet-1/manifests/site.pp:33 中不推荐使用“import”。请参阅http://links.puppetlabs.com/puppet-import-deprecation （在grammar.ra:610:in `_reduce_190'）
根据“要尝试的事情”下引用的 URL，它说“要将节点定义保存在单独的文件中，请指定一个目录作为主清单”。
"推荐：如果您大量使用主清单而不是依赖 ENC，请考虑将清单设置更改为 $confdir/manifests。这可以让您将顶级代码拆分为多个文件，同时避免使用 import 关键字。它也将匹配简单环境的行为。 ” …
我注意到一些 systemd 文档和操作文档中关于如何配置一个或多个服务以使用相同计时器的方法的一些显着变化。
就我已经能够拼凑起来（尽管我可能是错的）这将描述服务和计时器文件中的WantedBy和Unit参数需要设置为（此处不使用实际代码示例 - 以减少发布长度）用于单个服务，相反，使用单个计时器的多个服务配置：
单个服务的定时器
My.Service1 'WantedBy' Param: N/A (1)
My.Timer 'Unit' Param: My.Service1 (2)
My.Timer 'WantedBy' Param: MultiUser/Basic.Target (3)
(1)服务文件不需要带有 WantedBy 参数的 [Install] 部分。
(2)在计时器的 [Timer] 部分，Unit 参数应指向 My.Service1 服务文件。
(3)定时器文件有一个 WantedBy 参数，它指向一些将用于启动它的特殊系统目标。
多个服务的定时器
My.Service1 'WantedBy' Param: Timer.Target (1)
My.Service2 'WantedBy' Param: Timer.Target (1)
My.Service3 'WantedBy' Param: Timer.Target (1)
Timer 'Unit' Param: Timer.Target (2)
Timer 'WantedBy' Param: ???
(1)所有服务都需要使用 WantedBy 参数连接到同一个定义的目标。
(2) [Timer] Unit 参数也应该指向目标。
有关后一种配置的示例，请参阅此操作方法。我将其视为示例 1。但是，我发现了其他与此不同的操作示例（见下文）。 …
[免责声明：这个问题是基于有缺陷的印象。与以非常盐的小颗粒，或根本没有盐。]
作为一名 Linux 管理员，在将近十年没有接触 Windows 服务器之后，他不情愿地重新回到 Windows 管理中.
我仍然记得在 ADUC 中的某些对象（比如 Windows Server 2003）上有一个组策略选项卡的日子，比如 OU（如果我没记错的话），但现在 ADUC 和组策略现在看起来已经被隔离到不同的管理中控制台并取消链接，现在 GPMC 是 GPO 的地方。我相信这有一些很好的原因。但是，我现在有几个问题。
为什么 OU 的结构和名称，以及 GPO 与 ADUC 中实际 AD 对象的关联似乎与其对应的 GPMC 完全隔离？似乎 GP 管理员必须保持警惕，以模仿对 GPMC 中 ADUC 中 OU 的命名或结构所做的任何更改，但我可以看到这不可避免地会出错，因为错误和疏忽将不可避免地不时发生。
显然，IT 管理员应该足够聪明和警惕以确保没有任何不一致之处，但是从技术上讲，如何将 ADUC 和 GPMC 分离是一种实际的改进？似乎自动化和匹配验证检查两者之间的一致性不仅应该是可能的，而且是微不足道的。在 Windows Server 2003 中，GPO 似乎直接与 AD 对象本身相关联，因此无论您对它们做什么，GPO 都会跟随对象；而我在某处读到，就直接关联和链接而言，现在 GPO“不属于 AD 对象”。这种变化背后的原因是什么？
但也许我只是阅读了错误的文档并完全误解了情况[编辑：是]。
感谢您耐心地向 Linux 管理员解释这一点。