Re: [Puppet Users] facter 3 and at_exit
I've created https://tickets.puppetlabs.com/browse/FACT-1381 Thanks again. On Fri, Apr 1, 2016 at 5:42 PM Clay Caviness wrote: > On Fri, Apr 1, 2016 at 5:33 PM Peter Huene > wrote: > >> This is caused by how custom facts are resolved in Facter 3: namely that >> custom facts are resolved all at once and no further calls from Ruby into >> Facter's native implementation are expected when all resolutions have >> completed. The Facter module removes itself from the Ruby runtime after >> all resolutions complete, but before the Ruby runtime is shutdown (when >> at_exit callbacks would occur). This is why your at_exit callbacks can't >> find the Facter module; it's no longer there at that point. >> >> > Ah, interesting. Thanks. > > >> Looking things over, I believe it doesn't need to be implemented this >> way. The Facter module could outlive the Ruby runtime, allowing at_exit >> callbacks to still make use of Facter. This would require that the native >> implementation not attempt to clean up explicit GC registrations made from >> the module, which should be entirely unnecessary anyway since the Ruby >> runtime has (in theory at least) destroyed the GC heap when the Ruby >> runtime is shutdown. >> >> I haven't seen at_exit used in a custom fact before, so I'm interested in >> your use case. Given that I consider this behavior to be an implementation >> bug in Facter, would you mind opening a JIRA ticket at >> https://tickets.puppetlabs.com (project should be "FACT" for Facter) and >> detailing the use case? >> >> > We're using https://github.com/google/macops/blob/master/facter/cache.rb in > order to have some caching for long-resolving facts. > > We have an at_exit call there to save the cached facts if they've changed. > > I'll raise a ticket. > > -- 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/CANU2HrdOts1T6irZevEO_bQwiR1ZrTyTQZ0Ld4CbZNB2ryO0Gg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] facter 3 and at_exit
On Fri, Apr 1, 2016 at 5:33 PM Peter Huene wrote: > This is caused by how custom facts are resolved in Facter 3: namely that > custom facts are resolved all at once and no further calls from Ruby into > Facter's native implementation are expected when all resolutions have > completed. The Facter module removes itself from the Ruby runtime after > all resolutions complete, but before the Ruby runtime is shutdown (when > at_exit callbacks would occur). This is why your at_exit callbacks can't > find the Facter module; it's no longer there at that point. > > Ah, interesting. Thanks. > Looking things over, I believe it doesn't need to be implemented this way. > The Facter module could outlive the Ruby runtime, allowing at_exit > callbacks to still make use of Facter. This would require that the native > implementation not attempt to clean up explicit GC registrations made from > the module, which should be entirely unnecessary anyway since the Ruby > runtime has (in theory at least) destroyed the GC heap when the Ruby > runtime is shutdown. > > I haven't seen at_exit used in a custom fact before, so I'm interested in > your use case. Given that I consider this behavior to be an implementation > bug in Facter, would you mind opening a JIRA ticket at > https://tickets.puppetlabs.com (project should be "FACT" for Facter) and > detailing the use case? > > We're using https://github.com/google/macops/blob/master/facter/cache.rb in order to have some caching for long-resolving facts. We have an at_exit call there to save the cached facts if they've changed. I'll raise a ticket. -- 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/CANU2HrcEssvPngYWwbpDA-t1gWzYZgCWLCs2zTXLGqFR_uRy2A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] facter 3 and at_exit
Hi Clay,
On Fri, Apr 1, 2016 at 1:57 PM, Clay Caviness wrote:
> I've come across an issue with facter 3, when using at_exit. Basically,
> any at_exit blocks that refer to anything not in the top-level namespace
> (pardon my terminology) trigger an 'uninitialized constant' NameError. I
> think this is a namespace issue of some sort, but it's beyond my ken.
>
> To recreate:
> Create uninitialized.rb:
> require 'facter'
> at_exit { Facter.warn('Facter.warn at exit') }
> at_exit { puts 'puts at exit' }
> Facter.add('uninitialized_constant') do
> setcode do
> 'foo'
> end
> end
>
> Run facter:
> facter -p uninitialized_constant facterversion
> facterversion => 3.1.4
> uninitialized_constant => foo
> puts at exit
> /private/var/puppet/lib/facter/unint.rb:3:in `block in ':
> uninitialized constant Facter (NameError)
>
> Note that the 'puts' at_exit works, but not the one using Facter.warn.
>
This is caused by how custom facts are resolved in Facter 3: namely that
custom facts are resolved all at once and no further calls from Ruby into
Facter's native implementation are expected when all resolutions have
completed. The Facter module removes itself from the Ruby runtime after
all resolutions complete, but before the Ruby runtime is shutdown (when
at_exit callbacks would occur). This is why your at_exit callbacks can't
find the Facter module; it's no longer there at that point.
Looking things over, I believe it doesn't need to be implemented this way.
The Facter module could outlive the Ruby runtime, allowing at_exit
callbacks to still make use of Facter. This would require that the native
implementation not attempt to clean up explicit GC registrations made from
the module, which should be entirely unnecessary anyway since the Ruby
runtime has (in theory at least) destroyed the GC heap when the Ruby
runtime is shutdown.
I haven't seen at_exit used in a custom fact before, so I'm interested in
your use case. Given that I consider this behavior to be an implementation
bug in Facter, would you mind opening a JIRA ticket at
https://tickets.puppetlabs.com (project should be "FACT" for Facter) and
detailing the use case?
Thanks!
>
> This works fine in facter 2:
> $ sudo facter -p uninitialized_constant facterversion
> facterversion => 2.4.4
> uninitialized_constant => foo
> puts at exit
> Facter.warn at exit
>
> I've put all this up at
> https://gist.github.com/ccaviness/12b1db78c42283f4193a1709dd03a8ac
>
> --
> 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/CANU2HrfPkoYcZcEWUioiTbyeN-60KfceZx3d1UX5XzdL3atSqg%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CACZQQfNc01%2ByZBEOeDHTdbES5qVv8uiqQmnpB9sqSbRhE7zTRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] facter 3 and at_exit
I've come across an issue with facter 3, when using at_exit. Basically, any
at_exit blocks that refer to anything not in the top-level namespace
(pardon my terminology) trigger an 'uninitialized constant' NameError. I
think this is a namespace issue of some sort, but it's beyond my ken.
To recreate:
Create uninitialized.rb:
require 'facter'
at_exit { Facter.warn('Facter.warn at exit') }
at_exit { puts 'puts at exit' }
Facter.add('uninitialized_constant') do
setcode do
'foo'
end
end
Run facter:
facter -p uninitialized_constant facterversion
facterversion => 3.1.4
uninitialized_constant => foo
puts at exit
/private/var/puppet/lib/facter/unint.rb:3:in `block in ':
uninitialized constant Facter (NameError)
Note that the 'puts' at_exit works, but not the one using Facter.warn.
This works fine in facter 2:
$ sudo facter -p uninitialized_constant facterversion
facterversion => 2.4.4
uninitialized_constant => foo
puts at exit
Facter.warn at exit
I've put all this up at
https://gist.github.com/ccaviness/12b1db78c42283f4193a1709dd03a8ac
--
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/CANU2HrfPkoYcZcEWUioiTbyeN-60KfceZx3d1UX5XzdL3atSqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] MCO fails to listen to puppetmaster AMQ
HI all, Im playing around with PE 4.2, trying to learn MCO architecture I have 1 PE master on Ubuntu with AMQ broker 1 test node running Centos7 with PE agent 1 test node running Centos 5.7 with Open source puppet agent first question, is it possible to enable the open source puppet agent to talk to PE AMQ broker? Or can PE Master talk and manage PE agents only? 2nd question: my Centos7 (with PE agent) is setup correctly, I can run "mco ping" from PE Master and Centos7 replies back on Centos5, I installed mcollective rpm on this Centos5 node and configured my certs and priv/pub keys [root@centos57 ssl]# pwd /etc/mcollective/ssl [root@centos57 ssl]# tree . |-- ca.cert.pem |-- centos57.cert.pem |-- centos57.private_key.pem |-- clients | |-- peadmin-public.pem | `-- puppet-dashboard-public.pem |-- mcollective-private.pem `-- mcollective-public.pem 1 directory, 7 files I copied the* centos57.cert.pem, centos57.private_key.pem *files from the /var/lib/puppet/ssl dir. This node however isnt talking to Puppetmaster, cat /var/log/mcollective.log I, [2016-04-01T21:58:14.535657 #5270] INFO -- : activemq.rb:129:in `on_connectfail' TCP Connection to stomp+ssl://mcollective@puppetmaster2:61613 failed on attempt 42 E, [2016-04-01T21:58:44.537839 #5270] ERROR -- : activemq.rb:149:in `on_ssl_connectfail' SSL session creation with stomp+ssl://mcollective@puppetmaster2:61613 failed: nested asn1 error I, [2016-04-01T21:58:44.538121 #5270] INFO -- : activemq.rb:129:in `on_connectfail' TCP Connection to stomp+ssl://mcollective@puppetmaster2:61613 failed on attempt 43 E, [2016-04-01T21:59:14.539604 #5270] ERROR -- : activemq.rb:149:in `on_ssl_connectfail' SSL session creation with stomp+ssl://mcollective@puppetmaster2:61613 failed: nested asn1 error I, [2016-04-01T21:59:14.539953 #5270] INFO -- : activemq.rb:129:in `on_connectfail' TCP Connection to stomp+ssl://mcollective@puppetmaster2:61613 failed on attempt 44 E, [2016-04-01T21:59:44.541296 #5270] ERROR -- : activemq.rb:149:in `on_ssl_connectfail' SSL session creation with stomp+ssl://mcollective@puppetmaster2:61613 failed: nested asn1 error I, [2016-04-01T21:59:44.541629 #5270] INFO -- : activemq.rb:129:in `on_connectfail' TCP Connection to stomp+ssl://mcollective@puppetmaster2:61613 failed on attempt 45 E, [2016-04-01T22:00:14.543349 #5270] ERROR -- : activemq.rb:149:in `on_ssl_connectfail' SSL session creation with stomp+ssl://mcollective@puppetmaster2:61613 failed: nested asn1 error I, [2016-04-01T22:00:14.543682 #5270] INFO -- : activemq.rb:129:in `on_connectfail' TCP Connection to stomp+ssl://mcollective@puppetmaster2:61613 failed on attempt 46 my Centos57 mcollective server.cfg is setup like this main_collective = mcollective collectives = mcollective libdir = /usr/libexec/mcollective logfile = /var/log/mcollective.log loglevel = info daemonize = 1 # Plugins securityprovider = psk plugin.psk = unset connector = activemq plugin.activemq.pool.size = 1 plugin.activemq.pool.1.host = puppetmaster2 plugin.activemq.pool.1.port = 61613 plugin.activemq.pool.1.user = mcollective plugin.activemq.pool.1.password = gKtrMuPIK5k3Fh621FYX plugin.activemq.pool.1.ssl = true plugin.activemq.pool.1.ssl.ca = /etc/mcollective/ssl/ca.cert.pem plugin.activemq.pool.1.ssl.cert = /etc/mcollective/ssl/centos57.cert.pem plugin.activemq.pool.1.ssl.key = /etc/mcollective/ssl/centos57.private_key.pem plugin.activemq.heartbeat_interval = 120 plugin.activemq.max_hbrlck_fails = 0 # Security plugin settings (required): # --- securityprovider = ssl # SSL plugin settings: plugin.ssl_server_private = /etc/mcollective/ssl/mcollective-private.pem plugin.ssl_server_public = /etc/mcollective/ssl/mcollective-public.pem plugin.ssl_client_cert_dir = /etc/mcollective/ssl/clients plugin.ssl_serializer = yaml # Facts factsource = yaml plugin.yaml = /etc/mcollective/facts.yaml identity = centos57 Trying to understand what other config Im missing on my Centos57 box to make it listen to PE Master AMQ broker. Thanks! -- 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/9a7becdb-2e65-4ca1-bd33-badbaf2c8d06%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] unable to create home directory
On Friday, 1 April 2016 14:34:01 UTC+1, jcbollinger wrote: > > > > On Thursday, March 31, 2016 at 9:34:04 AM UTC-5, Warron French wrote: >> >> Isn't .ssh created after the first time a user attempts an SSH outbound >> connection, not at initial creation of homedirs? >> > > Inasmuch as we seem to be talking about OpenSSH or a work-alike, yes, the > ssh client creates the .ssh/ directory automatically at need. In no way > does that mean it cannot or should not be created by another mechanism, > however. The directory needs to exist so that Puppet can manage an > authorized key entry within. If it does not already exist at the time of > the catalog run, then Puppet needs to create it. Puppet is trying to do > so, but failing. > > > John > > To create the admin home directory first the ssh key resource should be dependent on an admin user resource. -- 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/73f22c33-579e-4853-852a-b1f1ac31d9f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Resources sharing across different classes.
On Friday, April 1, 2016 at 4:57:02 AM UTC-5, Afroz Hussain wrote:
>
> Hi Martin,
>
> Thanks for your help. I have tried your hack but didn't work, still same
> error,
> class addfile (
> $enable_notify => Service[’tomcat’],
> ) {
> file {‘/tmp/hello’:
> ensure => file,
> notify => $enable_notify,
> }
> }
>
> Technically, we can all any resource from any classes since all resources
> are unique across modules.
>
Yes, once declared, resources have global scope. You can refer to them
from any class, in any module or no module. Martin did not suggest
differently.
But the fact the you CAN access resources from anywhere does not mean it's
a good idea to do so. Whether it's reasonable in this particular case is
unclear, but doubtful, as for the most part the identities of the resources
declared by a given class should be considered implementation details of
that class, and depending on another class's implementation details makes
your class brittle.
That's not even the most significant problem here, however. Your
(original) Addfile class depends on there is a resource Service['tomcat']
declared for the target node. If this is sensible in all cases, then it
would be best for that class to take its own measures to ensure that its
requirement is satisfied, which would be best done by declaring the
appropriate class. For example, if Tomcat is managed via a "tomcat" class,
then you might use
class addfile {
include 'tomcat'
# ...
}
But that's a half measure. Remember that we should avoid depending on
implementation details of other classes. If you are prepared to rely on
the tomcat class to provide the needed service resource, then it is
probably best to make that class the target of the notification
relationship, instead of anything within that you rely on it to declare:
class addfile {
include 'tomcat'
file {"/tmp/hello":
ensure => file,
content => "hello"
}
~>
Class['tomcat']
}
Note, among other things, that that works fine if the name of the Tomcat
service differs from node to node, and that it does not break if the
service name changes (e.g. to "apache-tomcat") in the future.
Much of that is predicated on the idea that signaling Tomcat is a hard
requirement, however, and the nature of the error you reported suggests
that that might not be the case. If you want to use your Addfile class on
machines where Tomcat is not being managed, and on those machines,
therefore, not to notify Service['tomcat'], then you probably need a much
deeper re-design than just one class. Something along the lines of
Martin's suggested modification to your class could well be part of such a
redesign, but you need rather more.
Indeed, I suspect that the reason Martin's suggestion did not work for you
is that you do not appreciate how to use it. Modifying the class
definition as he described will not, in itself, make any difference at
all. To address your problem via his version of the class, you need to
also cause the correct data for the target node to be bound to the new
class parameter. But if that's as far as you go then it's just a stopgap.
I think you have deeper problems.
John
--
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/29f3ec07-5e5a-48c1-a46c-db16439f5b3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] unable to create home directory
On Thursday, March 31, 2016 at 9:34:04 AM UTC-5, Warron French wrote: > > Isn't .ssh created after the first time a user attempts an SSH outbound > connection, not at initial creation of homedirs? > Inasmuch as we seem to be talking about OpenSSH or a work-alike, yes, the ssh client creates the .ssh/ directory automatically at need. In no way does that mean it cannot or should not be created by another mechanism, however. The directory needs to exist so that Puppet can manage an authorized key entry within. If it does not already exist at the time of the catalog run, then Puppet needs to create it. Puppet is trying to do so, but failing. John -- 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/013a4657-2c91-4f19-986c-48e8aa45c035%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Resources sharing across different classes.
Hi Martin,
Thanks for your help. I have tried your hack but didn't work, still same
error,
class addfile (
$enable_notify => Service[’tomcat’],
) {
file {‘/tmp/hello’:
ensure => file,
notify => $enable_notify,
}
}
Technically, we can all any resource from any classes since all resources
are unique across modules.
Thanks,
Afroz Hussain
On Thursday, 31 March 2016 17:40:27 UTC+5:30, Martin Alfke wrote:
>
> Hi Arfoz,
>
> this is the best example on how to _not_ do classes.
> Every class should be self contained - as long as possible.
> In your case you have a hard reference from one resource inside a class to
> another resource inside another class.
> I always tell my training course attendees that they should never do this
> unless they don’t like themselves and they want to have Puppet nightmares.
>
> In your case you can do the following hack:
>
> make the add file class a parameterised class, set the parameter to the
> default behaviour:
>
> class addfile (
> $enable_notify => Service[’tomcat’],
> ) {
> file {‘/tmp/hello’:
> ensure => file,
> notify => $enable_notify,
> }
> }
>
> On systems where you don’t have tomcat class included you have to declare
> the class add file with parameter set to undef.
>
> But: be aware that even this is not a good solution.
> It’s just a hack.
> Try to refacter your modules.
>
> Best,
> Martin
>
>
> On 31 Mar 2016, at 13:48, Afroz Hussain >
> wrote:
>
> > Error as below:
> >
> > Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Invalid relationship: File[/tmp/hello] { notify => Service[tomcat]
> }, because Service[tomcat] doesn't seem to be in the catalog
> >
> > On Thursday, 31 March 2016 17:13:46 UTC+5:30, Afroz Hussain wrote:
> > Hi All,
> >
> > I am facing an issue to notify a service from different module whenever
> file changes.
> > Example:
> > I have a addfile module which creates a file and want to notify tomcat
> service which is present in tomcat module.
> >
> > class addfile {
> >file {"/tmp/hello":
> > ensure => file,
> > content => "hello",
> > notify => Service["tomcat'],
> >}
> > }
> >
> >
> > it is throwing an error as tomcat service is not in catalog.
> >
> > I have 3.6.2 version of puppet and using ENC.
> >
> > Any help will be appreciated
> >
> > Thanks,
> > Afroz Hussain
> >
> >
> > --
> > 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/02cfc06d-d306-48a2-a917-7144606a1509%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/d2a5cdb9-e49d-46eb-a67d-c650dae895b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
