On Tue, Jan 16, 2018 at 11:08 AM, jmp242 <jp10...@gmail.com> wrote:
> We serve multiple file resources depending on configuration via puppet to
> Windows 7 and Windows 10 workstations using FLOSS puppet. This was working
> with puppet agent 1.10.4 on clients and with puppet server (and foreman
> fwiw) 4 on Scientific Linux 7.4. Since we upgraded puppet server to
> 5.latest we started having issues with deploying certain, random but
> consistent file resources that had worked on the earlier version. In the
> logs we see various Error 500 messages - but they all seem to be blank
> (i.e. no further info than: Failed to generate additional resources using
> 'eval_generate': Error 500 on SERVER: Server Error) or not googleable. The
> files are still there and permissions look the same to me on the server.
> The manifest code hasn't changed. What's weirder is it seems like some file
> resources served like this are working.
>
> This problem is most prevalent with files served as a defined type so I
> wonder if something happened around that?
> file { "DesignData-${title}":
> path => "C:/VaultWorkspace/${title}/Vault/Design Data",
> source => "puppet:///modules/inventor/Design Data",
> recurse => true,
> purge => true,
> ensure => present,
> }
>
> Example defined type that's now failing with the above... We feed in an
> array of users and that's still being parsed correctly - logs show things
> like:
> //pc5102//Stage[main]/Inventor/Inventor::Designdata[
> username1]/File[DesignData-username1] :
> Failed to generate additional resources using 'eval_generate': Error 500
> on SERVER: Server Error
>
>
>
I think you're running into
https://tickets.puppetlabs.com/browse/SERVER-1954, which affects
puppetserver 5.x and up. There was a change in behavior in the bidi library
we use, which breaks serving files with URL special characters like spaces.
So high likelihood of breaking Windows agents.
> One other place that seems like a related file serving issue to me anyway
> is that I have an updated module to test (a forked reboot module) which I
> have deployed in my dev environment and code to use the new parameter,
> however when I try and apply the manifest I get errors - again 500 on
> server, this time that the new parameter doesn't exist. I'm wondering if
> this is also an issue with pluginsync or something like that so the client
> doesn't see the new module?
>
That sounds like a lack of environment isolation issue on the compile
master. See https://puppet.com/docs/puppet/5.3/environment_isolation.html.
>
> Any ideas as to what's gone wrong in the update?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/175349a2-26e3-40e1-b8f7-03e50a302919%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/175349a2-26e3-40e1-b8f7-03e50a302919%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Josh Cooper | Software Engineer
j...@puppet.com | @coopjn
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unGAGcO6a2FPgN%2BRPf9O%3Ds7dFa9RtFzxk%3Dj5-EXY%2BbPMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
