[Puppet Users] PE: Updating custom SSL certs

[J.T. Conklin]

I'm running PE 2016.4.3 in my home lab. About 90 days ago, I installed
SSL certificates I generated via Let's Encrypt for my puppet server as
described @ https://docs.puppet.com/pe/2016.4/custom_console_cert.html.

With the cert expiration near, I re-generated my certs, updated the
public-console.cert.pem and public-console.private_key.pem files in
/opt/puppetlabs/server/data/console-services/certs, and kicked off
puppet -- and nothing happened.  Is something else needed to make the
updated certs take effect?

   --jtc

-- 
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/87bmqqj12g.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] stop service after install

[John Gelnaw]

On Wednesday, May 17, 2017 at 5:06:33 PM UTC-4, Poil wrote:
>
> I'm agree with "Debian is just by design stupid, thinks starting all 
> services"
> All other integration are really fine, but  auto-starting after install is 
> terrible for all configuration management :
> Change a path (mysql binary log for example), a mount point (a LV for 
> mysql) before installing : Nope you can't
> You have to write a hack to remove all autostart from the package before 
> installing it that's incredible.
>
> I dream about a Debian mix with RedHat, RPM, no auto-start but all the 
> configuration system from Debian (splited-conf for apache php ... and tools 
> to manage your modules
>

Well, what you're complaining about is the package maintainers, not the 
OS-- it's the post install scripts that start up the services.  You might 
want to look into openSuSE-- RPM based, but package configuration tends to 
be more modular than Red Hat.  The openSuSE build service is also a nice 
feature.

You'll still run into the same thing with openSuSE and Red Hat-- RHEL7, if 
you install "nfs-utils" (traditionally the "nfs client" package-- but now 
it's the server package too), for example, you get the NFS server 
installed, running, set to auto-start, with portmapper running.

And I'm sure for every person who gripes about package X installing itself 
as 'autostart', you'll find at least one person who complains that they've 
got to enable the service after installation.

Personally, I don't care-- ultimately, I use puppet to ensure the package 
is installed, configured, and the service is enabled how *I* want it. 
 Nearly all of my configuration changes are linked to the service, so if I 
update a config file, the service is automatically restarted.  That's kind 
of the whole point of puppet.

Calling an OS "stupid" because they made decisions you disagree with is 
short-sighted.

-- 
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/c94494b2-a5f0-4132-8b8c-041baf174627%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] stop service after install

[Poil]

I'm agree with "Debian is just by design stupid, thinks starting all 
services"
All other integration are really fine, but  auto-starting after install 
is terrible for all configuration management :
Change a path (mysql binary log for example), a mount point (a LV for 
mysql) before installing : Nope you can't
You have to write a hack to remove all autostart from the package before 
installing it that's incredible.


I dream about a Debian mix with RedHat, RPM, no auto-start but all the 
configuration system from Debian (splited-conf for apache php ... and 
tools to manage your modules)



Le 17/05/2017 à 19:21, John Gelnaw a écrit :

On Monday, May 15, 2017 at 8:16:38 AM UTC-4, R.I. Pienaar wrote:


debian will not overwrite configs on package install - suggest you
put a
config down that does what you want first.


Or, I dunno, maybe he could could tie the service to the config file, 
and restart apache when the config file changes, and "require" the 
apache2 class as part of his nginx setup.


So Puppet would install apache (starting the service), install the 
config file (restarting apache), and then install nginx.


|
classapache2 {

  $pkglist =['apache2','apache2-dev',]

package{$pkglist:
ensure=>latest,
alias=>'apache2'
}
  file {'/etc/apache2/conf.d/ports.conf':
content =>'Listen 127.0.0.1:80',
require=>Package['apache2'],
notify =>Service['apache2']
}
  service {'apache2':
ensure=>running,
refreshonly =>true
}
}

classnginx {

requireapache2

package{...}

  service {...}

}
|

That's just off the top of my head, and isn't really The Right Way, 
but it's got all the components.


Debian is just by design stupid, thinks starting all services
unconfigured on install is a good idea, suggest you use a OS
designed to
be used on servers and not peoples basements.


That is probably the single worst piece of advice I've seen on this 
forum.  It's hostile, short-sighted, and not terribly useful.


Debian has been a better "server" OS for years, in that it supports 
in-place upgrades, and makes it easier to control which packages are 
installed from which repositories.


Our environment has about 200 web and database servers, about 60% of 
which are Red Hat, and the rest are Debian.  They're both perfectly 
good operating systems for production servers, but they do require the 
admin be open-minded enough to actually learn the differences between 
the two paradigms-- otherwise, you might as well run Windows.


--
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/a3979ccc-0761-4a26-8a3d-26d38ff7f6bb%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.



--
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/f8810064-75c6-ee73-5e45-4384b7ab471f%40quake.fr.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Have Puppet remove a user when the associated class which created it is removed

[John Gelnaw]

On Friday, May 5, 2017 at 2:22:27 PM UTC-4, James Perry wrote:
>
> As I keep tweaking our Puppet/Foreman setup, I was wondering if it was 
> somehow possible to auto-magically remove uses when the associated class is 
> removed from the server.  All of our Puppet code is under source code 
> management and requires a full change approval process to implement. 
>
> I thought of doing custom facts and then checking them against all user 
> classes, but that seemed like it would use a ton of overhead.  
>
> Another idea was to do a define that had a default of absent for a user 
> and then pass "present" as a parameter to have the user created, but that 
> seemed like it would still need some "magic" that most likely end up 
> getting really deep in coding to ensure that the user didn't get pulled off 
> a box where it needed to exist. 
>
> I'm not sure this is even possible other than how I have done it in the 
> past where I created 2 users classes. One that adds it and another that 
> removed it. The process is a bit clunky but it does work. 
>
> Anyone had any success making something like this work? 
>

Sort of?  The problem is, my implementation is very different from yours. 
 I'm managing users via YAML.  You can manage users (including removing 
them) via the user resource, so I'm creating YAML data (on the fly, but 
that's not a requirement) that gets consumed by a create_resources call.  I 
do management by invoking:

  resources { user:
purge  => true,
unless_system_user => $auth_base
  }

where $auth_base is the highest possible uid for a system user (usually 
999).  Then any users that aren't known to the puppet catalog are zorched.

-- 
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/f542a16c-029e-4d0a-8a24-0c1fed838d0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] stop service after install

[John Gelnaw]

On Monday, May 15, 2017 at 8:16:38 AM UTC-4, R.I. Pienaar wrote:
>
>
> debian will not overwrite configs on package install - suggest you put a 
> config down that does what you want first. 
>

Or, I dunno, maybe he could could tie the service to the config file, and 
restart apache when the config file changes, and "require" the apache2 
class as part of his nginx setup.

So Puppet would install apache (starting the service), install the config 
file (restarting apache), and then install nginx.

class apache2  {

  $pkglist = ['apache2', 'apache2-dev',  ]

  package { $pkglist:
 ensure   => latest,
 alias=> 'apache2'
  }
  file { '/etc/apache2/conf.d/ports.conf':
content => 'Listen 127.0.0.1:80',
require => Package['apache2'],
notify  => Service['apache2']
  }
  service { 'apache2':
ensure  => running,
refreshonly => true
  } 
}

class nginx  {

  require apache2

  package { ... } 

  service { ... }

}

That's just off the top of my head, and isn't really The Right Way, but 
it's got all the components.
 

> Debian is just by design stupid, thinks starting all services 
> unconfigured on install is a good idea, suggest you use a OS designed to 
> be used on servers and not peoples basements. 
>

That is probably the single worst piece of advice I've seen on this forum. 
 It's hostile, short-sighted, and not terribly useful.

Debian has been a better "server" OS for years, in that it supports 
in-place upgrades, and makes it easier to control which packages are 
installed from which repositories.

Our environment has about 200 web and database servers, about 60% of which 
are Red Hat, and the rest are Debian.  They're both perfectly good 
operating systems for production servers, but they do require the admin be 
open-minded enough to actually learn the differences between the two 
paradigms-- otherwise, you might as well run Windows.

-- 
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/a3979ccc-0761-4a26-8a3d-26d38ff7f6bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Scheduled_task?

[Josh Cooper]

On Wed, May 17, 2017 at 5:34 AM, Jason McMahan 
wrote:

> The full error is
>
> Error: Failed to call 
> #::NewWorkItem
> with HRESULT: -214702489
> 3.:  The system cannot find the path specified.
> Error: /Stage[main]/Profile::Windows::Applications::Sysinfo::Base/
> Scheduled_task[Automation/Inventory]/ensure
> : change from absent to present failed: Failed to call
> #::New
> WorkItem with HRESULT: -2147024893 <(214)%20702-4893>.:  The system
> cannot find the path specified.
>
> The folder exists but the task is not created nor seen.
>
> I believe i may just need to create it in the root but would like
> verification.
>
> Thank you
>
>
>
> On Tuesday, May 16, 2017 at 6:59:17 PM UTC-5, Jason McMahan wrote:
>>
>> Good day,
>> We were using the scheduled_task resource to create a task. It creates
>> the task however we nwed to create the task in a folder under task
>> scheduler.
>> \automation\inventory
>>
>> We tried name => '\automation\inventory\
>> But at run says can not find path.
>> We looked at working_dir but that didn't sound promising either. Any
>> suggestions would be greatly appreciated. Thank you
>>
> --
> 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/53648950-dc88-4188-b2e4-678a1a14dec0%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

Puppet only supports v1 of the Windows task scheduler API (which is present
in 2003 and up), so I'm inclined to think folders are a v2 API feature,
which is filed as https://tickets.puppetlabs.com/browse/PUP-6455.

Josh

-- 
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%2Bu97ukAMKHZDLmD-G8TyPDKNGYdDJf9uaVPW1AVgBdHOs3t9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet-Agent

[Josh Cooper]

On Sat, May 13, 2017 at 9:56 AM, Linux Info  wrote:

> Hello,
>
> I am trying to connect puppet master node(Centos-7) from fresh puppet
> agent node (Centos-7), but getting below errors while executing "puppet
> agent -t".
>
> [root@puppet_client_1 ~]# puppet agent -t
> Info: Creating a new SSL key for puppet_client_1
> Error: Could not request certificate: execution expired
> Exiting; failed to retrieve certificate and waitforcert is disabled
>
> Requesting to go through with attached logs to resolve this issue.
>
> Please let me know if you need any info for the same.
>
> Best Regards,
> Deepankar A
>
>
> --
> 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/CAD33ukGmU_NKBgRcEMGGDQ_LHziHOsUd54yxmJx_
> 4HFF4EEpJw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

By default puppet agents will try to connect to "puppet". You likely need
to specify the server to connect to (either on the command line or
puppet.conf), e.g. puppet agent -t --server .

Josh

-- 
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%2Bu97ukwHLYupbs%3DEnskrwE5AVHmrT%3Dd7a8oecXDP152zT9oyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Could not retrieve local facts: undefined method `require_relative' for main:Object

[R.I.Pienaar]

On Wed, May 17, 2017, at 16:34, Helen Paterson wrote:
> Hi,
> 
> im currently getting the following error on a few of my Ubuntu solr
> servers
> 
> Error: Could not retrieve local facts: undefined method
> `require_relative' 
> for main:Object
> Error: Failed to apply catalog: Could not retrieve local facts: undefined 
> method `require_relative' for main:Object
> 
> 
> we are running puppet agent 3.8 , im not sure how to debug ???

I would guess your ruby is too old for one of your facts,
require_relative is a ruby method that came in recently.

-- 
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/1495034663.745652.979740128.1B664CDD%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Could not retrieve local facts: undefined method `require_relative' for main:Object

[Helen Paterson]

Hi,

im currently getting the following error on a few of my Ubuntu solr servers

Error: Could not retrieve local facts: undefined method `require_relative' 
for main:Object
Error: Failed to apply catalog: Could not retrieve local facts: undefined 
method `require_relative' for main:Object


we are running puppet agent 3.8 , im not sure how to debug ???


Thanks 

Helen

-- 
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/a31aae49-3109-410a-b0e6-e588131dea6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] stop service after install

[Anton Gorlov]

Hi.
At the current moment I need bind  the apache to localhost:80 and nginx
to external_ip:80.
I cannot change nginx config before it installed and debian start nginx
automatic after install  package with  default configuration (bind to
*:80) => conflict.

So first I stop  the apache service, after install nginx and go update
config's...


14.05.2017 16:10, Poil пишет:
> Why do you want to stop it ? I think you want to change the listen port.
>
> So I think something like this will do the job :
>
> package { 'apache2': ensure => installed, }
>
> service { 'apache2':
>   ensure => running,
>   enable => true,
> }
>
> file { '/etc/apache2/conf.d/listen_port.conf':
>   content => "your_template.conf.erb",
>   require => Package['apache2'],
>   notify => Service['apache2'], # Refresh apache after the listen_port
> is changed
> }
>
> package {'nginx':
>   ensure => installed,
>   require => Service['apache2'], # Install nginx after apache have
> been restarted with another config
> }
>
>
> Le 13/05/2017 à 11:45, Anton Gorlov a écrit :
>> Hi.
>>
>> I need stop service (apache) after it install from puppet.
>> platform is debian 9 and puppet version is 4.8.2
>>
>> I my class i wrote:
>>
>> 
>> class webpackages {
>>
>> exec { 'apachechk':
>>  command => "/bin/systemctl stop apache2;",
>>  onlyif => "/bin/grep -c 'Listen 80' /etc/apache2/ports.conf",
>> }
>>
>> package { 'libapache2-mpm-itk':
>> ensure => latest,
>> }
>>
>> package { 'apache2':
>> require => Exec['apachechk'],
>> ensure => latest,
>> }
>>
>> package { 'apache2-dev':
>> ensure => latest,
>> }
>> package { 'apache2-suexec-pristine':
>> ensure => latest,
>> }
>> package { 'apache2-utils':
>> ensure => latest,
>> }
>> package { 'apache2-bin':
>> ensure => latest,
>> }
>> package { 'apachetop':
>> ensure => latest,
>> }
>> package { 'libapache2-mod-rpaf':
>> ensure => latest,
>> }
>> package { 'nginx-light':
>> require => Exec['apachechk'],
>> ensure => latest,
>> }
>>
>> }
>> ===
>>
>> but apache not stopping and install nginx is fail because port is busy
>> by apache
>>
>> May 13 12:21:29 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
>> [::]:8…se)
>> May 13 12:21:29 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
>> 0.0.0.…se)
>> May 13 12:21:29 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
>> [::]:8…se)
>> May 13 12:21:30 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
>> 0.0.0.…se)
>> May 13 12:21:30 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
>> [::]:8…se)
>> May 13 12:21:30 debian9-lab3 nginx[19538]: nginx: [emerg] still could
>> not bind()
>>
>> What is wrong and what is right way to do it?
>>
>

-- 
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/57fa4c2b-06b8-8663-daff-02cfdaeea65a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] "puppet agent -t" is not working in my agent node

[Sudhansu Swain]

while i am typing this command in agent  its not working. Nothing is 
happening.

Cannot generate the certificate at all. Pls help


-- 
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/18f17ebc-ae83-4bc7-8c9e-c1d7074ce2c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet-Agent

[Linux Info]

Hello,

I am trying to connect puppet master node(Centos-7) from fresh puppet agent
node (Centos-7), but getting below errors while executing "puppet agent -t".

[root@puppet_client_1 ~]# puppet agent -t
Info: Creating a new SSL key for puppet_client_1
Error: Could not request certificate: execution expired
Exiting; failed to retrieve certificate and waitforcert is disabled

Requesting to go through with attached logs to resolve this issue.

Please let me know if you need any info for the same.

Best Regards,
Deepankar A

-- 
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/CAD33ukGmU_NKBgRcEMGGDQ_LHziHOsUd54yxmJx_4HFF4EEpJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Puppet v3.8.7

[root@puppet_client_1 ~]# puppet agent -t
Info: Creating a new SSL key for puppet_client_1
Error: Could not request certificate: execution expired
Exiting; failed to retrieve certificate and waitforcert is disabled

[root@puppet_client_1 puppet]#  puppet agent --test --trace
Error: Could not request certificate: execution expired
/usr/share/ruby/net/http.rb:878:in `initialize'
/usr/share/ruby/net/http.rb:878:in `open'
/usr/share/ruby/net/http.rb:878:in `block in connect'
/usr/share/ruby/net/http.rb:877:in `connect'
/usr/share/ruby/net/http.rb:862:in `do_start'
/usr/share/ruby/net/http.rb:851:in `start'
/usr/share/ruby/net/http.rb:1373:in `request'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:208:in 
`execute_request'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:176:in `block (2 
levels) in request_with_redirects'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:219:in `block in 
with_connection'
/usr/share/ruby/vendor_ruby/puppet/network/http/nocache_pool.rb:15:in 
`with_connection'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:218:in 
`with_connection'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:173:in `block in 
request_with_redirects'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:170:in `upto'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:170:in 
`request_with_redirects'
/usr/share/ruby/vendor_ruby/puppet/network/http/connection.rb:76:in `get'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:83:in `http_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:62:in `http_get'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:96:in `block in find'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:190:in `block in 
do_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/request.rb:263:in `do_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:190:in `do_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:90:in `find'
/usr/share/ruby/vendor_ruby/puppet/indirector/certificate/rest.rb:12:in `find'
/usr/share/ruby/vendor_ruby/puppet/indirector/indirection.rb:201:in `find'
/usr/share/ruby/vendor_ruby/puppet/ssl/host.rb:206:in `certificate'
/usr/share/ruby/vendor_ruby/puppet/ssl/host.rb:36:in `localhost'
/usr/share/ruby/vendor_ruby/puppet/ssl/validator/default_validator.rb:29:in 
`initialize'
/usr/share/ruby/vendor_ruby/puppet/ssl/validator.rb:27:in `new'
/usr/share/ruby/vendor_ruby/puppet/ssl/validator.rb:27:in `default_validator'
/usr/share/ruby/vendor_ruby/puppet/network/http_pool.rb:35:in `http_instance'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:57:in `network'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:82:in `http_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:62:in `http_get'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:96:in `block in find'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:190:in `block in 
do_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/request.rb:263:in `do_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:190:in `do_request'
/usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:90:in `find'
/usr/share/ruby/vendor_ruby/puppet/indirector/certificate/rest.rb:12:in `find'
/usr/share/ruby/vendor_ruby/puppet/indirector/indirection.rb:201:in `find'
/usr/share/ruby/vendor_ruby/puppet/ssl/host.rb:206:in `certificate'
/usr/share/ruby/vendor_ruby/puppet/ssl/host.rb:326:in `wait_for_cert'
/usr/share/ruby/vendor_ruby/puppet/application/agent.rb:483:in 
`wait_for_certificates'
/usr/share/ruby/vendor_ruby/puppet/application/agent.rb:324:in `run_command'
/usr/share/ruby/vendor_ruby/puppet/application.rb:381:in `block (2 levels) in 
run'
/usr/share/ruby/vendor_ruby/puppet/application.rb:507:in `plugin_hook'
/usr/share/ruby/vendor_ruby/puppet/application.rb:381:in `block in run'
/usr/share/ruby/vendor_ruby/puppet/util.rb:496:in `exit_on_fail'
/usr/share/ruby/vendor_ruby/puppet/application.rb:381:in `run'

[Puppet Users] Re: Scheduled_task?

[Jason McMahan]

The full error is 

Error: Failed to call 
#::NewWorkItem 
with HRESULT: -214702489
3.:  The system cannot find the path specified.
Error: 
/Stage[main]/Profile::Windows::Applications::Sysinfo::Base/Scheduled_task[Automation/Inventory]/ensure
: change from absent to present failed: Failed to call 
#::New
WorkItem with HRESULT: -2147024893.:  The system cannot find the path 
specified.

The folder exists but the task is not created nor seen.

I believe i may just need to create it in the root but would like 
verification.

Thank you



On Tuesday, May 16, 2017 at 6:59:17 PM UTC-5, Jason McMahan wrote:
>
> Good day, 
> We were using the scheduled_task resource to create a task. It creates the 
> task however we nwed to create the task in a folder under task scheduler.
> \automation\inventory
>
> We tried name => '\automation\inventory\
> But at run says can not find path.
> We looked at working_dir but that didn't sound promising either. Any 
> suggestions would be greatly appreciated. Thank you 
>

-- 
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/53648950-dc88-4188-b2e4-678a1a14dec0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Error 400 on SERVER: Permission denied.

[Sandy]

Note - a puppet newbie here - any help is much appreciated :-)

We are getting a "Failed to generate additional resources using
'eval_generate': Error 400 on SERVER: Permission denied" whenever a file
being accessed/referenced via the file resource (directive) "recurse =
remote" function is not world readable on the puppet master. It does not
appear to be a file owner/group thing - it appears that all files within
the source tree actually require file level accessibility to be world
readable (004 mask) on the master so to deploy the file within a recursive
block to a node without the above error. This is on PE 3.7.2 CentOS 6.8.
Is this a bug? Is this a configuration setting? The thing is that this is
a blocker for us - we would like to deploy a directory tree but the world
permissions cannot have read access on the node once deployed.
huh?
Thanks in advance!

-- 
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/aab09cff-2d12-4094-99af-50e2558d6c72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.