Question

我正在尝试创建一个.ssh文件夹，然后将id_rsa和known_hosts文件添加到Windows 2016服务器中的.ssh文件夹中。此文件夹需要进入手动运行（或作为服务）运行puppet的任何用户。为了使此工作有效，我编写了一个自定义事实$ :: user_profile_directory，该目录显示了主目录（％userprofile％）。除了puppet作为服务运行之外，该方法对所有用户都完全适用。

当puppet作为服务运行时，它将在“ c：/ windows / system32 / config / systemprofile”文件夹内创建.ssh文件夹，但不会在已创建的.ssh文件夹文件夹（id_rsa文件known_hosts文件）中创建文件。如果以任何其他用户身份运行puppet服务，则不会发生这种情况。

Puppet也不在日志中显示任何错误，而是说内容已更改为特定的md5 sum哈希。但是，如果我使用资源管理器手动检查，.ssh文件夹将不包含任何文件。

此外，如果我手动将文件放入c：/windows/system32/config/systemprofile/.ssh文件夹，它还会更正文件的权限。我不明白，如果它能够纠正文件上的权限（如果存在），那么为什么它不能创建文件。这是我简单的木偶代码：

$user_home = $::user_profile_directory

  file { "${user_home}/.ssh":
    ensure => 'directory',
    #owner  => $user_name,
    group  => 'Administrators',
    mode   => '0700'
  } ->

  file { "${user_home}/.ssh/id_rsa":
    ensure  => 'file',
    content => hiera('vester::vester_private_key'),
    #owner   => $user_name,
    group   => 'Administrators',
    mode    => '0600'
  } ->

  file { "${user_home}/.ssh/known_hosts":
    ensure             => 'file',
    source             => 'puppet:///modules/vester/known_hosts',
    source_permissions => 'ignore',
    #owner              => $user_name,
    #group              => 'Administrators',
    #mode               => '0660'
  }

当木偶作为服务运行时： $ {user_home}是c：/ windows / system32 / config / systemprofile

当木偶以其他用户身份运行时（例如，无业游民）： $ {user_home}是c：/ users / vagrant

生成$ :: user_home事实的因子代码：

Facter.add('user_profile_directory') do
  confine :osfamily => :windows
  setcode do
    ENV['USERPROFILE']
  end
end

编辑1：刚想到，我可以创建文件夹，但不能在“ C：/ windows / system32”下的任何文件夹/子文件夹中创建文件。如何使用puppet在system32下的自定义文件夹中创建文件？？

编辑2：即使$ :: user_profile_directory返回

c：/ windows / system32 / config / systemprofile

我所有的文件都放在

下

c：/ windows / syswow64 / config / systemprofile

Answer 1

Puppet 32位客户端已安装在我的64位Windows 2016 Server上。实际上是在创建文件，而不是

c：/ windows / system32 /config/systemprofile/.ssh

文件是在

内部创建的

c：/ windows / syswow64 /config/systemprofile/.ssh

我的木偶客户端的

文件夹。

%windir%\System32目录是为64位Windows上的64位应用程序保留的。创建64位版本的DLL时，大多数DLL文件名都没有更改，因此32位版本的DLL存储在不同的目录中。 WOW64通过使用文件系统重定向器隐藏了这种差异。

在大多数情况下，每当32位应用程序尝试访问%windir%\System32，%windir%\lastgood\system32或`％windir％\ regedit.exe时，访问都会重定向到特定于体系结构的路径。< / p>

这很奇怪，即使文件是在c:/windows/syswow64/config/systemprofile/.ssh文件夹中创建的，事件查看器中的人偶日志也显示文件是在c:/windows/system32/config/systemprofile/.ssh内部成功创建的。发生这种情况是因为because 32位客户端不知道Windows中的秘密重定向。

对我来说，解决方法是仅删除32位puppet客户端并重新安装64位puppet客户端，因为我的一个puppet-modules（puppetlabs / vsrepo）试图访问c:/windows/system32/config/systemprofile/.ssh文件夹中的已知主机文件因为它在后台使用64位git.exe客户端。

More about the WOW64 secret redirection in Microsoft documentation here

木偶无法在C：\ windows \ system32文件夹中创建文件

1 个答案: