Re: [Puppet Users] Puppet Agent starting too soon

[Rob Nelson]

I'm guessing those race conditions are related to not replacing it with
something else. Seems they're "magic" components to not requiring reliance
on network-online.target. Hooray :/


Rob Nelson
rnels...@gmail.com

On Wed, Mar 29, 2017 at 9:24 AM, Trevor Vaughan 
wrote:

> I just ditched it.
>
> On Tue, Mar 28, 2017 at 9:23 AM, Rob Nelson  wrote:
>
>> Did you replace it with systemd-networkd, or just ditch it? Regardless,
>> I've updated us to EL7.3 (CentOS though) and not observed this issue, so
>> I'm not sure it's that generic of a problem, there must be *something*
>> triggering it. Even a simple race condition should result in some successes
>> if Laverne has rebooted it a few dozen times.
>>
>>
>> Rob Nelson
>> rnels...@gmail.com
>>
>> On Tue, Mar 28, 2017 at 9:08 AM, Trevor Vaughan 
>> wrote:
>>
>>> Disabling NetworkManager hasn't caused any issues for me so far. That
>>> said, EL7.3 might break that, so Fedora may already be broken.
>>>
>>> Trevor
>>>
>>> On Tue, Mar 28, 2017 at 9:00 AM, Rob Nelson  wrote:
>>>
 That wiki page says that all you should need to do is have
 NetworkManager or systemd-networkd services enabled. Do you by any chance
 have them both disabled on the affected node? I know many of us don't like
 NetworkManager, but disabling it entirely can cause some problems. Just a
 guess, as I haven't seen this issue on any of my nodes, including the
 low-RAM ones.


 Rob Nelson
 rnels...@gmail.com

 On Mon, Mar 27, 2017 at 11:33 PM, Laverne Schrock <
 lvernschr...@gmail.com> wrote:

> I have a box on which puppet-agent does not start correctly on reboot.
> Well, to be more precise, the puppet-agent starts, but never contacts the
> server.
>
>
> $ sudo journalctl -b 0 -u puppet -f
>> -- Logs begin at Wed 2017-02-01 18:27:11 CST. --
>> Mar 06 12:42:03 localhost.localdomain systemd[1]: Started Puppet agent.
>> Mar 06 12:42:16 localhost.localdomain puppet-agent[927]: Could not 
>> request certificate: getaddrinfo: Temporary failure in name resolution
>> Mar 06 12:44:16 a.real.hostname.tld puppet-agent[927]: Could not request 
>> certificate: getaddrinfo: Temporary failure in name resolution
>> Mar 06 12:46:16 a.real.hostname.tld puppet-agent[927]: Could not request 
>> certificate: getaddrinfo: Temporary failure in name resolution
>> Mar 06 12:48:16 a.real.hostname.tld puppet-agent[927]: Could not request 
>> certificate: getaddrinfo: Temporary failure in name resolution
>>
>>
> Note how when the puppet-agent starts, the box doesn't yet know its
> hostname because the network stack is (apparently) not fully up. Running
> `systemctl restart puppet` resolves the issue until the next reboot.
>
> I was able to find a work-around. In the systemd unit file for puppet,
> I changed
>
> After=basic.target network.target
>>
> to
>
>>  After=basic.target network-online.target
>>
>
> See: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
>
> The box is a fresh install of Fedora 25 and is using the following
> packages:
>
>> puppet-agent-1.9.3-1.fedoraf25.x86_64
>> puppetlabs-release-pc1-1.1.0-5.fedoraf25.noarch
>>
>
> I have another box with the same setup (but a little more RAM) and the
> issue does not occur there.
>
> I have two thoughts on this.
> 1) This is a subtle timing issue which is why I see it on one box, but
> not the other.
> 2) puppet-agent is misbehaving and ought to  properly detect when the
> networking stack comes up.
> 3) If I want to resolve this, I should just use my workaround.
>
> Does #3 seem like the best plan? I'd appreciate any insight into why
> the issue is occurring.
>
> Cheers,
> -Laverne Schrock
>
>
>
>
> --
> 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/36ca1e68-fa09
> -4654-ba62-9c13c2561c76%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/ms
 

Re: [Puppet Users] Re: puppetserver and LDAP terminus

[Steve Huston]

So big surprise to me when I'm looking to move our infrastructure from
openldap to freeipa, and having trouble getting puppetserver to talk
to it, when I find there was a reply to my posts that I'd missed.  And
sadly, there was no resolution then either.

Yes, jruby-ldap updating their code would be great, but they haven't
had any updates since 2012.  And this problem still exists.  And I've
found a new wrinkle - the same documentation that talks about using
the LDAP terminus also mentions using SSL or TLS, but trying to use
TLS fails with an error that there's too many arguments passed to the
open command ("Puppet Could not connect to LDAP: Could not connect to
LDAP: wrong number of arguments calling `initialize` (3 for 2)").

When I also found the ticket you referenced in this message, I saw
some comments about how this is a "dusty corner" of puppet.  That's
great, but either the problem needs to be fixed, or the whole of it
needs to stop being referenced as possible and supported when it is
obviously not.  If the former, I would imagine removing reliance on
jruby-ldap which is already shown to be broken is the way to go, and
if the latter is the case I will have to make my own modifications to
jruby-ldap to make it work, once I figure out what those modifications
should be.

On Tue, Jun 9, 2015 at 5:43 PM, Eric Sorenson
 wrote:
> Hi Steve, thanks for tracking this down! The LDAP node terminus is a useful
> but pretty cobwebby corner of Puppet (IIRC it predates the existence of the
> External Node Classifier API which is what most sites are using now). So as
> you found its docs do not get a lot of love and there are no acceptance/CI
> tests that cover its use.
>
> I have a couple of comments inline. Our education team ran across this
> issue, which is why I'm replying to a months-old thread. We're tracking it
> in JIRA at https://tickets.puppetlabs.com/browse/SERVER-711
>
> On Tuesday, February 3, 2015 at 2:40:50 PM UTC-8, Steve Huston wrote:
>>
>> So, I've spent another day beating on this problem and finally
>> achieved success.  We started with:
>>
>> > # puppetserver gem install ruby-ldap
>>
>> Nobody pointed out, either here or in the documentation, that when
>> using puppetserver you have to use "jruby-ldap" instead.  Once I did
>> that, the gem installed, yay!  But it still didn't work.  When the
>> server attempted to do a lookup it would still report that the search
>> failed, even though tcpdump showed it asking for the CN and getting
>> the right answer.
>>
>> After quite a bit of prodding and help from a colleague I found that
>> jruby-ldap does not have a to_hash method in LDAP::Entry.  This was
>> confirmed by a bit of code and comment at the top of
>>
>> https://github.com/alibby/ldap_authenticated/blob/master/lib/ldap_authenticated.rb
>>
>> I inserted that code into the ruby module, since I would have to
>> manually upgrade that but the puppetserver RPM might get upgraded (and
>> wipe out that change), and got a little further.  Now, however, it
>> failed with another error: "Puppet Cannot reassign variable macaddress
>> on node syrinx.astro.princeton.edu"
>
>
> It seems like the to_hash change would be better off as a patch to the
> upstream module vs a monkey-patch in Puppet.
>
>>
>>
>> On our old server running under passenger, if I look at
>> /var/lib/puppet/yaml/node/syrinx.astro.princeton.edu I see there's
>> both a "macaddress" and a "macAddress", so I realized what's going on
>> - the downcase in that code snippet is causing two facts to appear at
>> once.
>
>
> That's not great either :(
>>
>>
>> All in all, this tells me a few things:
>>
>> 1) The documentation for using LDAP with the new puppetserver needs to
>> be updated to reflect not only that one must use 'jruby-ldap' (and
>> puppetserver gem install at that) but that the tests listed (running
>> ruby -rpuppet -e 'p Puppet.features.ldap?' and such) are incorrect as
>> they will report 'true' if you have the gem installed through the
>> normal system commands but puppetserver will not see it.
>
>
> That's true. Would you be willing to work up a pull request against the
> puppet-docs repo with the things you've learned? The source markdown for the
> guide is here:
>
> https://github.com/puppetlabs/puppet-docs/blob/master/source/guides/ldap_nodes.markdown
>
>>
>>
>> 2) There needs to be a patch, perhaps somewhere in puppetserver, that
>> makes sure the jruby-ldap LDAP::Entry class has a 'to_hash' method (or
>> code around the necessity of needing it), for example:
>>
>> if RUBY_PLATFORM =~ /^java.*/i
>>   class LDAP::Entry
>>  def to_hash
>> h = {}
>> get_attributes.each { |a| h[a.to_sym] = self[a] }
>> h[:dn] = [dn]
>> h
>>  end
>>   end
>> end
>
>
> As I said, I think this would be better as an upstream patch to the
> jruby-ldap project, especially since you found another project that had to
> do the same thing.  Carrying individual monkey-patches 

Re: [Puppet Users] Custom Facts using awk

[Joshua Schaeffer]

Excellent. Good to know. I was told otherwise.

Thanks,
Joshua Schaeffer

On Wednesday, March 29, 2017 at 7:11:55 AM UTC-6, Gabriel Schuyler wrote:
>
> Never fear, external facts work just fine in Puppet 3.
>
> On Tuesday, March 28, 2017 at 10:51:52 AM UTC-4, Joshua Schaeffer wrote:
>>
>> External facts are a Puppet v4 feature only. You have to use Ruby to 
>> create custom facts in Puppet v3.
>>
>> On Monday, March 27, 2017 at 3:54:00 PM UTC-6, Warron French wrote:
>>>
>>> OK, done, and done.  But it still isn't showing up.
>>>
>>> Is this potentially because I am using PE-3.8 as a component of Red Hat 
>>> Satellite?
>>>
>>> --
>>> Warron French
>>>
>>>
>>> On Mon, Mar 27, 2017 at 5:28 PM, Peter Bukowinski  
>>> wrote:
>>>
 Hi Warron,

 Puppet executes the script directly, so you need the shebang line and 
 you must ensure the file is executable.

 -- Peter

 On Mar 27, 2017, at 2:25 PM, warron.french  wrote:

 Peter, perhaps I misunderstood you; but, I thought I was supposed to be 
 able to use bash or sh scripting to generate facters of my own without the 
 use of Ruby.

 The link you provided refers to a python script example.  It also adds 
 a shebang line at the top of the script; do I need the shebang line, or 
 will Puppet simply execute the shell script with:

 sh scriptname.sh

 Thanks for the feedback,

 --
 Warron French


 On Wed, Mar 22, 2017 at 7:07 PM, Peter Bukowinski  
 wrote:

> Hi Warron,
>
> I'd consider using an external, executable fact to avoid ruby 
> altogether.
>
>   
> https://docs.puppet.com/facter/3.6/custom_facts.html#executable-facts-unix
>
> Basically, you can write a bash script (or use any language you want),
> drop it into '//facts.d/' on your puppet server,
> and it will be synced to all your nodes (assuming you use pluginsync).
>
> The only requirement for executable fact scripts is that they must
> return key/value pairs in the format 'key=value'. Multiple keys/values
> get their own line. In your case, you could do something like this:
>
> -
> #!/bin/bash
>
> key="qty_monitors_total"
> value=$(your parsing command for /var/log/Xorg.0.log here)
>
> echo "${key}=${value}"
> -
>
> Save the file as an executable script in the above mentioned path and
> it should be available on the next puppet run.
>
> On Wed, Mar 22, 2017 at 3:24 PM, warron.french  
> wrote:
> > Hello, I have finally learned how to write a Custom Fact; and 
> duplicated the
> > syntax several times over inside the same .rb file.
> >
> > I am using syntax that looks like the following:
> >
> > Facter.add('qty_monitors_total') do
> >   setcode  do
> >  Facter::Util::Resolution.exec('/bin/grep " connected"
> > /var/log/Xorg.0.log | cut -d\) -f2,3,4 | grep GPU |sort -u | wc -l')
> >   end
> > end
> >
> > I don't know of any other way to do this yet; but that's not my 
> concern yet.
> >
> > What I would like to know is how can I use an awk command within the
> > Facter::Util::Resolution.exec('.') line.
> >
> > I have a need to essentially reproduce the line above but drop   wc 
> -l and
> > add awk '{ print $2"_"$3"_on_"$1$4 }'
> >
> > I need the awk command to pretty much look like this; the problem is 
> awk
> > uses its own single quotes (') and it will break the ruby code.
> >
> > I am not a ruby developer; so if someone could either tell me:
> >
> > It's just not possible; or
> > do it this way
> >
> >
> > That would be greatly appreciated.  Thank you,
> >
> > --
> > Warron French
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit
> > 
> https://groups.google.com/d/msgid/puppet-users/CAJdJdQmZXQAd%2Bo%2Bnp-NHqxGHnXubf%2Bac-dP5FPoy4QYMEVuBuA%40mail.gmail.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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/CAJA1CN9aFH4Eza-FoxzrfXDWiGCUHXE%2BGFt2Nu%3DjK2eDzV4upg%40mail.gmail.com
> .

Re: [Puppet Users] Puppet Agent starting too soon

[Trevor Vaughan]

I just ditched it.

On Tue, Mar 28, 2017 at 9:23 AM, Rob Nelson  wrote:

> Did you replace it with systemd-networkd, or just ditch it? Regardless,
> I've updated us to EL7.3 (CentOS though) and not observed this issue, so
> I'm not sure it's that generic of a problem, there must be *something*
> triggering it. Even a simple race condition should result in some successes
> if Laverne has rebooted it a few dozen times.
>
>
> Rob Nelson
> rnels...@gmail.com
>
> On Tue, Mar 28, 2017 at 9:08 AM, Trevor Vaughan 
> wrote:
>
>> Disabling NetworkManager hasn't caused any issues for me so far. That
>> said, EL7.3 might break that, so Fedora may already be broken.
>>
>> Trevor
>>
>> On Tue, Mar 28, 2017 at 9:00 AM, Rob Nelson  wrote:
>>
>>> That wiki page says that all you should need to do is have
>>> NetworkManager or systemd-networkd services enabled. Do you by any chance
>>> have them both disabled on the affected node? I know many of us don't like
>>> NetworkManager, but disabling it entirely can cause some problems. Just a
>>> guess, as I haven't seen this issue on any of my nodes, including the
>>> low-RAM ones.
>>>
>>>
>>> Rob Nelson
>>> rnels...@gmail.com
>>>
>>> On Mon, Mar 27, 2017 at 11:33 PM, Laverne Schrock <
>>> lvernschr...@gmail.com> wrote:
>>>
 I have a box on which puppet-agent does not start correctly on reboot.
 Well, to be more precise, the puppet-agent starts, but never contacts the
 server.


 $ sudo journalctl -b 0 -u puppet -f
> -- Logs begin at Wed 2017-02-01 18:27:11 CST. --
> Mar 06 12:42:03 localhost.localdomain systemd[1]: Started Puppet agent.
> Mar 06 12:42:16 localhost.localdomain puppet-agent[927]: Could not 
> request certificate: getaddrinfo: Temporary failure in name resolution
> Mar 06 12:44:16 a.real.hostname.tld puppet-agent[927]: Could not request 
> certificate: getaddrinfo: Temporary failure in name resolution
> Mar 06 12:46:16 a.real.hostname.tld puppet-agent[927]: Could not request 
> certificate: getaddrinfo: Temporary failure in name resolution
> Mar 06 12:48:16 a.real.hostname.tld puppet-agent[927]: Could not request 
> certificate: getaddrinfo: Temporary failure in name resolution
>
>
 Note how when the puppet-agent starts, the box doesn't yet know its
 hostname because the network stack is (apparently) not fully up. Running
 `systemctl restart puppet` resolves the issue until the next reboot.

 I was able to find a work-around. In the systemd unit file for puppet,
 I changed

 After=basic.target network.target
>
 to

>  After=basic.target network-online.target
>

 See: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

 The box is a fresh install of Fedora 25 and is using the following
 packages:

> puppet-agent-1.9.3-1.fedoraf25.x86_64
> puppetlabs-release-pc1-1.1.0-5.fedoraf25.noarch
>

 I have another box with the same setup (but a little more RAM) and the
 issue does not occur there.

 I have two thoughts on this.
 1) This is a subtle timing issue which is why I see it on one box, but
 not the other.
 2) puppet-agent is misbehaving and ought to  properly detect when the
 networking stack comes up.
 3) If I want to resolve this, I should just use my workaround.

 Does #3 seem like the best plan? I'd appreciate any insight into why
 the issue is occurring.

 Cheers,
 -Laverne Schrock




 --
 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/ms
 gid/puppet-users/36ca1e68-fa09-4654-ba62-9c13c2561c76%40goog
 legroups.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/ms
>>> gid/puppet-users/CAC76iT_vimf_MmN--mBLA2fnqSAxQUJ%3DBAzNRMOQ
>>> OgM1F0TevA%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699 x788 

Re: [Puppet Users] Custom Facts using awk

[Gabriel Schuyler]

Never fear, external facts work just fine in Puppet 3.

On Tuesday, March 28, 2017 at 10:51:52 AM UTC-4, Joshua Schaeffer wrote:
>
> External facts are a Puppet v4 feature only. You have to use Ruby to 
> create custom facts in Puppet v3.
>
> On Monday, March 27, 2017 at 3:54:00 PM UTC-6, Warron French wrote:
>>
>> OK, done, and done.  But it still isn't showing up.
>>
>> Is this potentially because I am using PE-3.8 as a component of Red Hat 
>> Satellite?
>>
>> --
>> Warron French
>>
>>
>> On Mon, Mar 27, 2017 at 5:28 PM, Peter Bukowinski  
>> wrote:
>>
>>> Hi Warron,
>>>
>>> Puppet executes the script directly, so you need the shebang line and 
>>> you must ensure the file is executable.
>>>
>>> -- Peter
>>>
>>> On Mar 27, 2017, at 2:25 PM, warron.french  wrote:
>>>
>>> Peter, perhaps I misunderstood you; but, I thought I was supposed to be 
>>> able to use bash or sh scripting to generate facters of my own without the 
>>> use of Ruby.
>>>
>>> The link you provided refers to a python script example.  It also adds a 
>>> shebang line at the top of the script; do I need the shebang line, or will 
>>> Puppet simply execute the shell script with:
>>>
>>> sh scriptname.sh
>>>
>>> Thanks for the feedback,
>>>
>>> --
>>> Warron French
>>>
>>>
>>> On Wed, Mar 22, 2017 at 7:07 PM, Peter Bukowinski  
>>> wrote:
>>>
 Hi Warron,

 I'd consider using an external, executable fact to avoid ruby 
 altogether.

   
 https://docs.puppet.com/facter/3.6/custom_facts.html#executable-facts-unix

 Basically, you can write a bash script (or use any language you want),
 drop it into '//facts.d/' on your puppet server,
 and it will be synced to all your nodes (assuming you use pluginsync).

 The only requirement for executable fact scripts is that they must
 return key/value pairs in the format 'key=value'. Multiple keys/values
 get their own line. In your case, you could do something like this:

 -
 #!/bin/bash

 key="qty_monitors_total"
 value=$(your parsing command for /var/log/Xorg.0.log here)

 echo "${key}=${value}"
 -

 Save the file as an executable script in the above mentioned path and
 it should be available on the next puppet run.

 On Wed, Mar 22, 2017 at 3:24 PM, warron.french  
 wrote:
 > Hello, I have finally learned how to write a Custom Fact; and 
 duplicated the
 > syntax several times over inside the same .rb file.
 >
 > I am using syntax that looks like the following:
 >
 > Facter.add('qty_monitors_total') do
 >   setcode  do
 >  Facter::Util::Resolution.exec('/bin/grep " connected"
 > /var/log/Xorg.0.log | cut -d\) -f2,3,4 | grep GPU |sort -u | wc -l')
 >   end
 > end
 >
 > I don't know of any other way to do this yet; but that's not my 
 concern yet.
 >
 > What I would like to know is how can I use an awk command within the
 > Facter::Util::Resolution.exec('.') line.
 >
 > I have a need to essentially reproduce the line above but drop   wc 
 -l and
 > add awk '{ print $2"_"$3"_on_"$1$4 }'
 >
 > I need the awk command to pretty much look like this; the problem is 
 awk
 > uses its own single quotes (') and it will break the ruby code.
 >
 > I am not a ruby developer; so if someone could either tell me:
 >
 > It's just not possible; or
 > do it this way
 >
 >
 > That would be greatly appreciated.  Thank you,
 >
 > --
 > Warron French
 >
 > --
 > 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...@googlegroups.com.
 > To view this discussion on the web visit
 > 
 https://groups.google.com/d/msgid/puppet-users/CAJdJdQmZXQAd%2Bo%2Bnp-NHqxGHnXubf%2Bac-dP5FPoy4QYMEVuBuA%40mail.gmail.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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/puppet-users/CAJA1CN9aFH4Eza-FoxzrfXDWiGCUHXE%2BGFt2Nu%3DjK2eDzV4upg%40mail.gmail.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 

Re: [Puppet Users] Re: Restore of puppet server vm

[Ryan Vande]

Thank you for that information Joshua !

On Monday, March 27, 2017 at 11:45:54 AM UTC-5, Joshua Schaeffer wrote:
>
> I'm not sure of any time specific settings in Puppet itself. You could 
> restore the VM again and then make sure your time settings are correct 
> before connecting anything to it. Also I was looking at the error log you 
> posted earlier. It is reporting a 404 error. Is that port open? Is 
> something listening on that port?
>
> netstat -tupan | grep 4432
>
> Thanks,
> Joshua Schaeffer
>
> On Monday, March 27, 2017 at 5:47:24 AM UTC-6, Ryan Vande wrote:
>>
>> I don't know, my system time is correct... It might had been off at the 
>> beginning but as of now it is correct might have I already did the damage 
>> and now its stuck being broke forever?
>>
>> On Monday, March 27, 2017 at 1:53:36 AM UTC-5, Ryan Vande wrote:
>>>
>>> There is a date time thing I noticed for sure, as of now the date time 
>>> his correct on Linux but I believe puppet does not believe so
>>>
>>> Is there a way I can update ntp just for puppet?
>>>
>>> Thank you for stating this, I do believe this is the issue
>>>
>>> Can we discuss more?
>>>
>>> On Mar 26, 2017 4:16 PM, "Joshua Schaeffer"  
>>> wrote:
>>>
 This is just a guess, but make sure the time on your server is 
 accurate. I do something similar with my agents where I have a base 
 (clean) 
 system, snapshot it, then run a puppet agent on it to test new modules, 
 changes, etc. If I need to make any changes to Puppet and want to start 
 from a clean install I just restore the snapshot and start over. The way I 
 snapshot'ed my system it restores the date and time of the server and 
 system state when the snapshot was taken. I have to specifically tell ntp 
 to update the time. Other system state information like memory and current 
 processes don't seem to affect the Puppet run, but if the date is not 
 accurate the Puppet agent complains.

 Again, just a guess, but make sure that if you are restoring the exact 
 system state that is is not interfering with Puppet operations.

 Thanks,
 Joshua Schaeffer

 On Saturday, March 25, 2017 at 8:20:11 PM UTC-6, Ryan Vande wrote:
>
> I got this from console-services.log
>
> "
>
> 2017-03-25 22:10:48,337 [qtp1717623735-78] INFO  [p.c.class-updater] 
> Synchronized 0 classes from the Puppet Master in 0 seconds
> 2017-03-25 22:10:48,580 [qtp1495082648-137] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/puppet_enterprise::profile::master
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@5371cc29
> 2017-03-25 22:10:48,586 [qtp1495082648-60] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/puppet_enterprise::profile::master::mcollective
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@106e6d
> 2017-03-25 22:10:48,597 [qtp1495082648-129] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/pe_repo
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@7dd91e98
> 2017-03-25 22:10:48,606 [qtp1495082648-128] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/puppet_enterprise::profile::mcollective::peadmin
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@7c9dc4a6
> 2017-03-25 22:10:48,654 [qtp1495082648-136] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/pe_repo::platform::el_7_x86_64
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@58e2612b
> 2017-03-25 22:11:55,025 [qtp1495082648-128] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/pe_repo
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@5cea3920
> 2017-03-25 22:11:55,078 [qtp1495082648-62] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/puppet_enterprise::profile::master
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@2881f554
> 2017-03-25 22:11:55,186 [qtp1495082648-61] ERROR [p.p.c.classes] 
> Failed to process classes request to 
> http://127.0.0.1:4432/classifier-api/v1/environments/production/classes/puppet_enterprise::profile::mcollective::peadmin
>  
> with code 404 org.apache.http.nio.entity.ContentInputStream@64783995
> 2017-03-25 22:11:55,200 [qtp1495082648-129] 

[Puppet Users] Clarification on mount type behaviour

[apgriffiths79]

Hi,

>From my testing it seems that when managing mount resources puppet only 
compares the manifest against fstab and not mtab. For example if I have

mount { '/tmp':
  ensure  => mounted,
  options => 'noexec,nodev,nosuid',
}

And then do mount -o remount,exec /tmp

I would expect the next puppet run to correct this, but I'm not seeing 
this, only if I edit fstab is the resource updated. Is this expected 
behavior?

(Running 4.9).

Thanks,

Alan

-- 
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/af5363b2-ba6e-4572-9218-f4b0742ad21c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.