Re: [Puppet Users] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
- "Al @ Lab42" wrote: > > BTW, an implementation question. How do you suggest to manage the > triggering of an action on the mcollective client from the > PupetMaster, after a Puppet run on one of its clients? > I suppose that using a custom report is the most logic approach, but > what's the sanest way to actually deliver it? Having a service > listening on a mcollective client node and send reports there? Using > stomp messaging? How? > I'd run it in the postrun_command script on each node, else I guess a report isnt too bad but reports kind of only work when a whole lot of other stuff was working as well at the same time. -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
On Oct 19, 11:06 pm, "R.I.Pienaar" wrote: > - "Al @ Lab42" wrote: > > > > > Hi List, > > I would like to discuss with whoever is interested one topic that I > > suppose has general interest. > > > I want to implement some kind of automatic testing on the status of a > > node after a Puppet Run. > > These tests involve trivial and less trivial things things like: > > - A local service is running > > - A local port is open > > - A remote server on a remote port is reachable by the node > > - An URL replies with an expected content > > - Some specific function needed by the node and provided by a remote > > host is working (ie: ldap acces for users authentication, ntp > > sync...) > > - Whatever other check that asserts that the node is correctly > > working > > sounds like things you want to monitor anyway in an ongoing manner? Generally yes. > > So assuming you have monitoring for all of this, is the problem that you > want visibility of the state right now after a run and not when nagios > gets round to doing its next checks which might be many minutes? Yes, but also I want direct correlation between a puppet run and an eventual failure. > I favor nrpe - cos I can deploy my check logic with puppet - but I really > think you want your monitoring to cover all of this. > > To answer the 'now' part of it, I'd just notify via mcollective my nagios > box to do a check for all services on the node post puppet run. That could be an option but it wouldn't directly correlate the check's failure with a Puppet run. I think I would prefer to use the existing checks (so nrpe is perfect) but be able run them also outside Nagios. BTW, an implementation question. How do you suggest to manage the triggering of an action on the mcollective client from the PupetMaster, after a Puppet run on one of its clients? I suppose that using a custom report is the most logic approach, but what's the sanest way to actually deliver it? Having a service listening on a mcollective client node and send reports there? Using stomp messaging? How? Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
On Oct 19, 10:52 pm, Nicolas Szalay wrote: > - "Al @ Lab42" a écrit : > > | Hi List, > > Hi, > > | I would like to discuss with whoever is interested one topic that I > | suppose has general interest. > | > | I want to implement some kind of automatic testing on the status of a > | node after a Puppet Run. > | These tests involve trivial and less trivial things things like: > | - A local service is running > | - A local port is open > | - A remote server on a remote port is reachable by the node > | - An URL replies with an expected content > | - Some specific function needed by the node and provided by a remote > | host is working (ie: ldap acces for users authentication, ntp > | sync...) > | - Whatever other check that asserts that the node is correctly > | working > | > | I want to do this directly in my modules, at least for the checks > | that are directly related to the resources provided by the module > | and > | build some defines to manage quickly things like "check the url" or > | "check if the remote port is accessible". > | > | The point is to have a solid testing infrastructure, early > | notification of any problem that might take place after a Puppet run > | and, at the same time have a sort of monitoring logic that might be > | used also by other tools, like Nagios. > > Do you know about puppet-cucumber ? Yes, but as far as I've understood, puppet-cucumber is run on the Puppet Master and check resources managed by Puppet. I'd like also to make checks that might not be directly related to Puppet resources (but might be broken by a wrong config pushed via Puppet). > > | In order to achieve something like this there are different > | approaches and I would like to follow what seems most sane and, > | mostly, what could better fit the evolution of the Puppet ecosystem. > | > | Here a pair of examples: > | > | - APPROACH 1 - CHECK TRIGGERED BY PUPPET NODE > > This is an easy approach but how will you push information back to you ? I > have not checked but I don't think that the result of post run hooks are > included into reports In fact, and that's a reason why I don't prefer this approach, because you should build your own reporting stuff. > > | - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE > > I would use that one, combined with nagios through the mc nrpe agent probably > or something like a hudson instance to do a permanent check about this. +1 > > | Another point is how to organize and define the checks' list. > | Cucumber > | seems a nice and somehow "standard" way to define the checks logic, > | but could be also a plain execution of the different checks from a > | sort of wrapper script. > | The single checks could be nrpe commands and/or mcollective agents (I > | love the nettest one, incidentally). > | > | > | AFAIK there's nothing in the above examples that is particularly > | difficult or can't be done with existing tools, but I would like to > | introduce them seamlessly in my modules (using my monitoring > | abstraction classes). > | > | So, I wonder if someone is already doing similar checks, what's the > | approach they are following and what might be the evolution of Puppet > | under regarding these topics. > > Not doing it but definitely interested. I'll let you know if I make up something interesting :-) Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] 2.6 upgrade problem
Maybe I'm dense, but that bug doesn't seem to be relevant. I just created #5048; I am not sure that the trace adds much, but hopefully someone can make something out of it. Thanks! - Chad On Tue, Oct 19, 2010 at 11:01 PM, James Turnbull wrote: > Chad Huneycutt wrote: >> I am attempting to upgrade my master from 0.25.5 to 2.6.2 and am stuck >> on this issue. The master seems to be be happily compiling catalogs, >> but the 0.25.5 clients cannot apply them. The error looks like this: >> >> info: Caching catalog for foo.bar.org >> /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:135: warning: >> Object#type is deprecated; use Object#class >> /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:135: warning: >> Object#type is deprecated; use Object#class >> err: Could not run Puppet configuration client: No title provided and >> "" is not a valid resource reference >> >> Catalogs seem to apply fine on the master (2.6.2 client). Obviously, >> there isn't a lot to go on, so any hints would be greatly appreciated. >> > > Odd. Can you please log a ticket with full --debug --trace output logs? > > How did you perform the upgrade? > > Also have a look at: > > http://projects.puppetlabs.com/issues/4778 > > And see if that seems familiar? > > Regards > > James Turnbull > > -- > Puppet Labs - http://www.puppetlabs.com > C: 503-734-8571 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] 2.6 upgrade problem
Chad Huneycutt wrote: > I am attempting to upgrade my master from 0.25.5 to 2.6.2 and am stuck > on this issue. The master seems to be be happily compiling catalogs, > but the 0.25.5 clients cannot apply them. The error looks like this: > > info: Caching catalog for foo.bar.org > /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:135: warning: > Object#type is deprecated; use Object#class > /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:135: warning: > Object#type is deprecated; use Object#class > err: Could not run Puppet configuration client: No title provided and > "" is not a valid resource reference > > Catalogs seem to apply fine on the master (2.6.2 client). Obviously, > there isn't a lot to go on, so any hints would be greatly appreciated. > Odd. Can you please log a ticket with full --debug --trace output logs? How did you perform the upgrade? Also have a look at: http://projects.puppetlabs.com/issues/4778 And see if that seems familiar? Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Is there an "official" unofficial source ppa?
Todd Eddy wrote: > Our organization uses Ubuntu LTS releases, problem being is there are > a few packages I want to keep up to date like subversion and puppet. > There are more-or-less "official" PPAs for at least subversion > (https://launchpad.net/~svn/+archive/ppa) and git (https:// > launchpad.net/~git-core/+archive/ppa). Is there anything similar for > puppet? I've looked and all the puppet ppas I see on there seem to be > run by individuals and/or not up to date. Mattias Gug maintains the most up-to-date: https://launchpad.net/~mathiaz/+archive/puppet-backports James -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Is there an "official" unofficial source ppa?
Our organization uses Ubuntu LTS releases, problem being is there are a few packages I want to keep up to date like subversion and puppet. There are more-or-less "official" PPAs for at least subversion (https://launchpad.net/~svn/+archive/ppa) and git (https:// launchpad.net/~git-core/+archive/ppa). Is there anything similar for puppet? I've looked and all the puppet ppas I see on there seem to be run by individuals and/or not up to date. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] 2.6 upgrade problem
I am attempting to upgrade my master from 0.25.5 to 2.6.2 and am stuck on this issue. The master seems to be be happily compiling catalogs, but the 0.25.5 clients cannot apply them. The error looks like this: info: Caching catalog for foo.bar.org /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:135: warning: Object#type is deprecated; use Object#class /usr/lib/ruby/site_ruby/1.8/puppet/resource.rb:135: warning: Object#type is deprecated; use Object#class err: Could not run Puppet configuration client: No title provided and "" is not a valid resource reference Catalogs seem to apply fine on the master (2.6.2 client). Obviously, there isn't a lot to go on, so any hints would be greatly appreciated. -- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] how to set Ruby path?
How do I set the Ruby path that Puppet uses? I have Ruby Enterprise Edition installed for my *application*, installed from source and symlinked (/usr/local/bin/ruby) so it's in the path, overriding the default .deb installed standard Ruby (/usr/bin/ruby). For *Puppet* I want to use the standard Ruby (/usr/bin/ruby). I'm seeing some hangs during my Puppet runs and I'm trying to see if it's because it's using REE (even though I installed it as a standard Ruby gem). I'm using standalone Puppet, version 2.6.1, installed via gem on Debian. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] ANNOUNCE: Puppet Dashboard 1.0.4 released!
We're pleased to announce the availability of Puppet Dashboard 1.0.4! This is a maintenance release, it fixes a number of bugs, improves the user interface, significantly boosts performance and includes better RPM and DEB packages. The source code of 1.0.4 is identical to 1.0.4rc2. Please upgrade to this stable release and let us know about any issues on the mailing list (http://groups.google.com/group/puppet-users/), or in the ticket tracker with an "Affected Version" of 1.0.4 (http://projects.puppetlabs.com/projects/dashboard/). If you're interested in what we're hoping to work on next, please see our roadmap (http://projects.puppetlabs.com/projects/dashboard/roadmap/). We would also appreciate it if you watched and commented on those tickets that are important to you. INSTALLING AND UPGRADING: New installation and upgrading instructions are available in the included README, which you can also read online at: http://github.com/puppetlabs/puppet-dashboard/blob/v1.0.4/README.markdown IMPORTANT: This release involves database migrations. Please see the README.markdown for instructions on applying them. USING RPM AND DEB PACKAGES: Install an the software using packages, which will put the files into your "/usr/share/puppet-dashboard" directory: Install the RPM package for CentOS or RHEL 5.5 by running: sudo sh -c "rpm -Uvh http://yum.puppetlabs.com/base/puppetlabs-repo-3.0-2.noarch.rpm; \ rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm; \ yum install puppet-dashboard" Or install the DEB package for Ubuntu 10.04: 1. Put the following in your "/etc/apt/sources.list.d/puppet-labs.list" file: deb http://apt.puppetlabs.com/ubuntu lucid main deb-src http://apt.puppetlabs.com/ubuntu lucid main 2. Run the command: sudo sh -c "wget -q -O - http://yum.puppetlabs.com/RPM-GPG-KEY-puppetlabs | sudo apt-key add - && \ apt-get update && apt-get install puppet-dashboard" USING THE SOURCE: You can download the release candidate from: http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.0.4.tgz Or check it out using git: git clone git://github.com/puppetlabs/puppet-dashboard.git && \ cd puppet-dashboard && \ git checkout v1.0.4 RELEASE NOTES: v1.0.4 -- * MIGRATION: Fixed truncation of long reports and deleted these invalid records. Please reimport your reports (see README) after migrating to readd these deleted reports. * MIGRATION: Fixed slow database queries and improved table indexes to speed up the home page, reports listing page, site-wide sidebar, nodes counts, and selection of nodes over time. * MIGRATION: Fixed orphaned records left behind when classes or groups were deleted, and removed these orphans from the database. * MIGRATION: Fixed duplicate membership records by removing them and preventing new ones from being added, e.g. a node belongs to the same class or group multiple times. * Fixed user interface for specifying classes and groups to work with standards-compliant browsers, autocomplete on keystroke rather than submitting, etc. * Fixed default node search, it was incorrectly using the "ever failed" node query rather than the "all" nodes query. * Fixed .rpm and .deb packages to include all required files, declare all dependencies, set correct permissions and include working startup scripts. * Fixed run-failure chart to correctly count the reports by day. * Fixed run-time chart to correctly display its unit-of-measure labels as seconds, not milliseconds. * Fixed report display and sorting to use the time the report was created by a client, rather than the time it was imported. * Fixed class validations to accept valid Puppet class names, including those with correctly-placed dashes, double-colons and numbers. * Fixed cycle exception caused when a node belonged to two or more groups that inherited a single, common group. * Fixed parameter inheritance so that a node belonging to a group can see the parameters it inherited from its groups' ancestors. * Fixed parameter collision to display errors if the same parameter was defined differently by groups at the same level of inheritance (e.g. both parents). * Fixed views to display all dates and times in the same timezone and format. * Fixed class edit form to use new-style form that can display error messages. * Fixed node to recalculate its latest report if the current report record was deleted. * Fixed external node classifier so Puppet can classify unknown nodes using its local file-based classification, rather than halting with errors. * Fixed node, class, and group listing pages to describe the current search and non-matches correctly. * Fixed views to generate all internal links relative to RAILS_ROOT enabling the site to be served from sub-URIs (Ex: example.com/dashboard/). * Fixed documentation for adding the EPEL repository on CentOS and RHEL hosts. * Fixed documentation to use sh-compatible commands and explain that this is the expected shell fo
Re: [Puppet Users] Re: Negate or uninclude a class
On Tue, Oct 19, 2010 at 09:00:16AM -0700, jcbollinger wrote:
> The subclass approach definitely does not override the superclass to
> do nothing. Much to the contrary, it overrides the superclass so that
> together (whether the superclass is directly included or not) they
> ensure the correct configuration for a system that is not, in the
> example, an LDAP client. In other words, the servers are configured
> as non-clients, rather than leaving their client status unmanaged.
> There will be file differences between clients and non-clients, and
> possibly differences in such things as installed packages and service
> configuration. It is wise to manage those differences, whether
> whether via subclassing or otherwise.
That's topsy turvy, in my opinion. I agree with you about the
importance of state, but in that scenario, to me, not being an LDAP
client is the basic state. The basic, clean state of a system should be
something Puppet protects from the start; including classes should
modify or extend that and, in most cases, I expect my configuration to
be protective enough of the core and well known functionality so that
it should make no difference whether a class was previously included and
then dropped or never included in the first place.
Here's my rationale: most of us do not have the luxury of knowing
everything about every aspect of every package that may be installed on
a typical Linux/*nix system (unless you're the chief architect at Red
Hat/SuSE or wherever, in which case you may have a shot). That isn't a
terrible problem; we can know enough about the core to be aware of what
is significant. I certainly know enough about the core components of a
system (nsswitch, pam, fstab and so on), to know what will interfere
with that and what is irrelevant. The seed of any configuration, for
me, would be locking those down in their simple and functional state.
This means that including an ldap::client will extend that, but in the
absence of ldap::client, the core function will be restored. There are
cases where the past inclusion of a class will litter a system with
packages and configuration that do interfere, but those are rare. I do
not share your nervousness about purging - purge and well managed
resources - and judicious use of virtual ones - is generally cleaner
than a whole set of twinned active/inactive classes. It doesn't mean I
never, ever write a disable/cleanup class but it isn't my habit.
It's a defensive approach but, given that I'm not Red Hat's chief
architect, lack the time to weigh every package in the balance but do
have responsibility for relatively up to date Red Hat and Centos systems
(Debian too, but that's a slower moving target), it seems to me both
saner and less work than adding disable classes to everything. It's
also less work and the code is cleaner, so I'd probably do it even if I
were the very source of all knowledge of RHEL's eccentricities.
My basic samba class configures a minimal smb.conf to be aware of the local
workgroup/domain but have no shares and explicitly disables all
samba-related services. samba::member, samba::pdc and others inherit
and extend. No longer including them undoes the damage, so to speak.
This is more than semantic quibbling about how to label different
states; inheriting and overriding a more complex state to impose a
simpler state is not the same as defaulting to the simpler state.
So in my situation, "if { include class }" works very well.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: client won't use remote file bucket
luke.bigum wrote: > Sorry should have said that. 2.6.2 client and server running on CentOS > 5. Stock CentOS ruby (1.8.5), server runs via Passenger and Ruby > Enterprise 1.8.7. > And no errors in the debug logs? Can you pastie some --debug --trace logs? Thanks James -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Application Server Deployment
hi could u pls explain me why cos i need to decide on C.M tool very soon. could u suggest some other tool. thanks On Tue, Oct 19, 2010 at 11:12 PM, Scott Smith wrote: > I highly suggest you refrain from using Puppet to manage service-level > applications. > > On Mon, Oct 18, 2010 at 1:19 AM, ajax wrote: > >> Hello all, >> >> I wanted to know can i deploy Application Severs like JOnAS (java) >> using Puppet from the server. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > -- > http://about.me/scoot > http://twitter.com/ohlol > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Thank you and Regards Ajinkya Prabhune -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Application Server Deployment
I highly suggest you refrain from using Puppet to manage service-level applications. On Mon, Oct 18, 2010 at 1:19 AM, ajax wrote: > Hello all, > > I wanted to know can i deploy Application Severs like JOnAS (java) > using Puppet from the server. > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- http://about.me/scoot http://twitter.com/ohlol -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Automating infrastructure tests on Puppet nodes after a puppetrun
- "Al @ Lab42" wrote: > Hi List, > I would like to discuss with whoever is interested one topic that I > suppose has general interest. > > I want to implement some kind of automatic testing on the status of a > node after a Puppet Run. > These tests involve trivial and less trivial things things like: > - A local service is running > - A local port is open > - A remote server on a remote port is reachable by the node > - An URL replies with an expected content > - Some specific function needed by the node and provided by a remote > host is working (ie: ldap acces for users authentication, ntp > sync...) > - Whatever other check that asserts that the node is correctly > working sounds like things you want to monitor anyway in an ongoing manner? So assuming you have monitoring for all of this, is the problem that you want visibility of the state right now after a run and not when nagios gets round to doing its next checks which might be many minutes? I favor nrpe - cos I can deploy my check logic with puppet - but I really think you want your monitoring to cover all of this. To answer the 'now' part of it, I'd just notify via mcollective my nagios box to do a check for all services on the node post puppet run. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Automating infrastructure tests on Puppet nodes after a puppetrun
- "Al @ Lab42" a écrit : | Hi List, Hi, | I would like to discuss with whoever is interested one topic that I | suppose has general interest. | | I want to implement some kind of automatic testing on the status of a | node after a Puppet Run. | These tests involve trivial and less trivial things things like: | - A local service is running | - A local port is open | - A remote server on a remote port is reachable by the node | - An URL replies with an expected content | - Some specific function needed by the node and provided by a remote | host is working (ie: ldap acces for users authentication, ntp | sync...) | - Whatever other check that asserts that the node is correctly | working | | I want to do this directly in my modules, at least for the checks | that are directly related to the resources provided by the module | and | build some defines to manage quickly things like "check the url" or | "check if the remote port is accessible". | | The point is to have a solid testing infrastructure, early | notification of any problem that might take place after a Puppet run | and, at the same time have a sort of monitoring logic that might be | used also by other tools, like Nagios. Do you know about puppet-cucumber ? | In order to achieve something like this there are different | approaches and I would like to follow what seems most sane and, | mostly, what could better fit the evolution of the Puppet ecosystem. | | Here a pair of examples: | | - APPROACH 1 - CHECK TRIGGERED BY PUPPET NODE This is an easy approach but how will you push information back to you ? I have not checked but I don't think that the result of post run hooks are included into reports | - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE I would use that one, combined with nagios through the mc nrpe agent probably or something like a hudson instance to do a permanent check about this. | Another point is how to organize and define the checks' list. | Cucumber | seems a nice and somehow "standard" way to define the checks logic, | but could be also a plain execution of the different checks from a | sort of wrapper script. | The single checks could be nrpe commands and/or mcollective agents (I | love the nettest one, incidentally). | | | AFAIK there's nothing in the above examples that is particularly | difficult or can't be done with existing tools, but I would like to | introduce them seamlessly in my modules (using my monitoring | abstraction classes). | | So, I wonder if someone is already doing similar checks, what's the | approach they are following and what might be the evolution of Puppet | under regarding these topics. Not doing it but definitely interested. Nico. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Negate or uninclude a class
On Tue, Oct 19, 2010 at 01:36:25PM +0200, Felix Frank wrote:
>
> Subclasses that effectively disable a class are a sound concept.
Subclasses which disable a resource are a sound concept; subclasses
which attempt to negate a claass present many problems, some of which I
have described, none of which you hae addressed.
> How
> this has to be achieved in any specific case can be somewhat
> mind-boggling,
Yes, indeed. All the problems of virtual resources, other included
classes, requirement to extend the disabling class every time the basic
class is changed and so on. And you've presented no solutions to any of
those.
> but the variable approach has severe limitations of its own.
>
> 1. Where is the variable set? You have probably no problem when using
> external node definition, but not everybody does.
You can do it in an internal node definition too. Is there a law
against node definitions in your manifests? But let's assume somebody
doesnt' want to or cannot use nodes. That isn't a problem; I've
designed Puppet configurations that used no nodes at all, or a default
node which simply included a class based on the node's hostname. Still
works - just declare the variable at the right level.
> You cannot define the
> variable in an arbitrary part of your manifest, because you can be
> afflicted by both ordering and scoping issues.
I wouldn't try to declare it in an arbitrary location. I would declare
it in an appropriate location.
>
> 2. The concept of dynamic scoping is going away in future versions (at
> least that is what seems to be a community consensus). Again, if you can
> globally assign the variable value to your node, this is not a problem.
It's not that I'm in love with the way Puppet uses variables - I
certainly amd not - my objection is to the concept of trying to negate a
class by individually trying to break or undo all it's effects. That
latter option is a horrible mess. Unless the community also proposes to
do away with "if", "case" and selectors, there is always going to be a
way of saying "if { include ldap::client }" and that is
always going to be a better solution for the problem *as described by
the original poster*, which is what I was answering.
> But if you want to for every node that includes class B to automatically
> not include class A, you're out of luck (this is true in many cases
> today already, because of the scoping issues).
Well, you've finally given an example that raises a genuine problem, but
the first thing to say is that it's not the problem described by the
poster. Secondly, the problem you describe can be solved by some
variant of
if $variable {
include A
} else {
include B
}
Even if we outlaw simple variables, there are other ways to to signal
state; parameterized classes, defines, creative abuse of virtual
defines, all of them are better than the idea of negating a class
resource by resource.
>
> Variables are about as far as you can get from a panacea in the puppet
> DSL. Granted, class inheritance can be clumsy, awkward and
> unmaintainable in many cases.
Class inheritance is very elegant when used for what it is good for. It
is bad for the purposes of the original poster.
> But all that and more applies to variables
> as well, and it seems to me that variables are going to become a lot
> less useful for such purposes in the future.
Wonderful. As I said, I'm not in love with Puppet's variables. I've
worked with declaritive languages before - done major projects in XSLT
and XSLT - and I'll be delighted to see more structured, less messy ways
of working. I'd be even more delighted to see some of what are
currently functions become genuine keywords. But if you're telling me
that the community is not just proposing to remove dynamic variable
scope but also to remove the ability to say "if { include
class }", not provide any alternatives and force people to have to
clumsily override every resource in a class which they never wanted to
include in the first place, then I'm afraid that the community is an
ass. Hopefully, that's not what you're telling me.
--
Bruce
It is impolite to tell a man who is carrying you on his shoulders that
his head smells.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: client won't use remote file bucket
That was meant to read "Clients run stock CentOS ruby (1.8.5), server
runs via Passenger and Ruby Enterprise 1.8.7."
On Oct 19, 5:02 pm, "luke.bigum" wrote:
> Sorry should have said that. 2.6.2 client and server running on CentOS
> 5. Stock CentOS ruby (1.8.5), server runs via Passenger and Ruby
> Enterprise 1.8.7.
>
> On Oct 19, 4:58 pm, James Turnbull wrote:
>
> > luke.bigum wrote:
> > > Hi all,
>
> > > I'm having a stupid moment getting a remote file bucket working. My
> > > client only file buckets locally, not remotely.
>
> > > I have this site.pp:
> > > *
> > > filebucket { "main": server => "puppet" }
> > > File { backup => "main" }
> > > node 'default' {
> > > include test
>
> > What Puppet version?
>
> > Regards
>
> > James Turnbull
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: client won't use remote file bucket
Sorry should have said that. 2.6.2 client and server running on CentOS
5. Stock CentOS ruby (1.8.5), server runs via Passenger and Ruby
Enterprise 1.8.7.
On Oct 19, 4:58 pm, James Turnbull wrote:
> luke.bigum wrote:
> > Hi all,
>
> > I'm having a stupid moment getting a remote file bucket working. My
> > client only file buckets locally, not remotely.
>
> > I have this site.pp:
> > *
> > filebucket { "main": server => "puppet" }
> > File { backup => "main" }
> > node 'default' {
> > include test
>
> What Puppet version?
>
> Regards
>
> James Turnbull
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Negate or uninclude a class
On Oct 18, 10:24 am, Bruce Richardson wrote: > Class inheritence *only* makes sense if you want to > override the properties of resources. It appears that we agree there. I add that one property shared by most resources is "ensure", by which relevant resources can be ensured absent / disabled (among other things). > The OP wants not to include a > whole class; what you're telling him to do is not uninclude the class, > but to try and override properties in every resource owned by the class, > so as to make the class effectively do nothing. The OP asked about how to "uninclude" a whole class -- that is, given the class being included in one part of a manifest, how to elsewhere cause it to not be included after all. We agree that cannot be done. One alternative approach is to include the class conditionally in the first place, a different alternative is to override it where needed. *Neither* is what the OP actually asked for. The subclass approach definitely does not override the superclass to do nothing. Much to the contrary, it overrides the superclass so that together (whether the superclass is directly included or not) they ensure the correct configuration for a system that is not, in the example, an LDAP client. In other words, the servers are configured as non-clients, rather than leaving their client status unmanaged. There will be file differences between clients and non-clients, and possibly differences in such things as installed packages and service configuration. It is wise to manage those differences, whether whether via subclassing or otherwise. > There are any number of > reasons why that's not a smart thing to do, but here are several that > occur to me immediately. [...] All the reasons cited boil down to this: the superclass and subclass must be structured suitably and be tightly coupled in order to work correctly. This is true generally of Puppet subclassing. It may constitute too great a barrier for some uses, but that does not invalidate the approach in general. How that relates to the OP's problem depends on his manifests. > Your exmaple cannot achieve the same effect as not including a class; > the empty files you'd litter the filesystem with is only one example. > Forcibly negating everything in a class is not the same as not including > it. Why not just not include it? The subclass approach indeed does not have the same effect as not including a class in the first place, but that's not exactly what the OP asked for. As described above, it also wouldn't be the best practice, because it would leave client status unmanaged on the servers. Whatever problems the subclass appoach has, though, empty files is not one of them. Perhaps you're looking at how in my simplified example I overrode the "source" property of a File resource. That contemplates a situation where you want the file present in any case, but with different content (e.g. /etc/nsswitch.conf). If you only want the file present at all in one case or the other then you would override the "ensure" property instead. > > For example, although Bruce's main suggestion could be used if for > > some reason it were important to avoid subclasses, really in that case > > something akin to his define-based suggestion (but without subclasses) > > would be better. That way, if the LDAP client somehow gets turned on > > on your LDAP server, then Puppet will turn it back off. Unconfigured > > means "I don't care"; it must not be confused with "off". The > > subclass usage pattern above achieves the same thing with no > > conditional inclusions and no define, plus it's safe against inclusion > > of "ldap::client" by other parts of the manifest. > > I'm sorry, but I think you are quite wrong and your recommendations are > very unwise. Then we will have to agree to disagree on that point. It is altogether independent of the subclassing question, however, and I think it very important, so I repeat: "Unconfigured means 'I don't care'; it must not be confused with 'off'." For example, if it is important that a system not be configured as an LDAP client, then its manifests should affirmatively make that so. It is not sufficient just to leave the client configuration out of its manifest. What if an admin (or a bad Puppet manifest) enables the LDAP client on a system that should not have it? Or what if one wants to convert a client to a server? You do not need to use subclasses to address the problem (the define-based approach could do it), but merely omitting the client configuration from the machine's manifest doesn't cut it. > I have no objection to class inheritance at all, although > the way it works in puppet is often misunderstoon and it is often > overused as a result. We agree on this. All too often, Puppeteers inherit from a class where it would be better to include that class. > Your proposed example is definitely not a good > use of class inheritance. My example was a schematic of the form, not a
Re: [Puppet Users] client won't use remote file bucket
luke.bigum wrote:
Hi all,
I'm having a stupid moment getting a remote file bucket working. My
client only file buckets locally, not remotely.
I have this site.pp:
*
filebucket { "main": server => "puppet" }
File { backup => "main" }
node 'default' {
include test
What Puppet version?
Regards
James Turnbull
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] setting type defaults in some classes
On Tue, Oct 19, 2010 at 3:06 AM, Bruce Richardson wrote:
> On Tue, Oct 19, 2010 at 11:32:26AM +0200, Arnau Bria wrote:
>> I don't remember from where I took the idea... but seems that I chose
>> wrong place :-) What do you recommend me? any doc to follow?
>
> Unfortunately, I don't think there is great documentation out there; the
> core development team is too busy and so are most of the users.
> Documentation lags behind. I'd love to add better documentation to
> Puppet but I have a very busy and stressful job, so I fail too. But in
> any case...
Even if people don't have time to provide documentation, it would be
extremely helpful if people filed clear bugs/features against the
documentation so we know what you really want to see.
This also means when someone decides to work on improving the docs,
there is a reasonably clear list of priorities.
http://docs.puppetlabs.com/contribute.html
>
>> > the included class had better be in the file found by the
>> > autoloader). I hope that's a little clearer.
>>
>> Reading your answer (and if I thought a little more about it before), my
>> question
>> could be answered by myself. As you say import "inserts" code, so
>> having 2 diff defaults in 2 diff sites does not make much sense, or does not
>> behave as I wish.
>
> Great! Now that you understand better how imports and includes work,
> you're answering your own questions. I bet you can work out a better
> way of laying out your manifests for yourself.
>
> The best advice I can give you is to work with the way puppet
> module/class autoloading works, not against it.
>
>>
>> If I redefine File defaults in comuting_bacula (in the class, not
>> module) it's evaluted and it's more important:
>>
>> class computing_bacula {
>> File { mode => 755 }
>> }
>> File { 'kaka' }
>>
>> on client:
>> notice: /Stage[main]/Computing_bacula/File[kaka]/mode: mode changed '666' to
>> '755'
>>
>>
>> So class defaults "are more important" than site dfaults.
>
> If there is a conflict between an already declared default and a new
> default, the new default wins. If there is no conflict, they are added
> together. If you go back to my example, I set a default of "ensure =
> file" at the top level. Because none of the later defaults had an
> "ensure" parameter, all files inherited that default. I also set "mode
> = 750" at the top level, but in some places I later declared "mode"
> again. In such cases, the declaration in the most immediate scope
> always wins.
>
> --
> Bruce
>
> What would Edward Woodward do?
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAky9bZQACgkQtkVqYTMBSwFdBACeI6QKolxGcX0CarlNOSpoJLAH
> WiYAn3YGrDGWqt6etbuECtja6SWPQAoH
> =Eqvm
> -END PGP SIGNATURE-
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Automating infrastructure tests on Puppet nodes after a puppetrun
Hi List, I would like to discuss with whoever is interested one topic that I suppose has general interest. I want to implement some kind of automatic testing on the status of a node after a Puppet Run. These tests involve trivial and less trivial things things like: - A local service is running - A local port is open - A remote server on a remote port is reachable by the node - An URL replies with an expected content - Some specific function needed by the node and provided by a remote host is working (ie: ldap acces for users authentication, ntp sync...) - Whatever other check that asserts that the node is correctly working I want to do this directly in my modules, at least for the checks that are directly related to the resources provided by the module and build some defines to manage quickly things like "check the url" or "check if the remote port is accessible". The point is to have a solid testing infrastructure, early notification of any problem that might take place after a Puppet run and, at the same time have a sort of monitoring logic that might be used also by other tools, like Nagios. In order to achieve something like this there are different approaches and I would like to follow what seems most sane and, mostly, what could better fit the evolution of the Puppet ecosystem. Here a pair of examples: - APPROACH 1 - CHECK TRIGGERED BY PUPPET NODE After the Puppet run a script/command is launched and makes the necessary checks (built on the node in a dinamic way, according to the modules installed). If I'm not wrong in recent Puppet versions there's an hook that makes you run custom commands after (or before? or both?) the execution of the puppet run, so this might be the way to automate the start of the checks without too many hassles. The cons are that everything is done on the node and there's not (if not implemented specifically) a centralized management of checks runs, process logic, notifications and history. - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE This somehow intrigues me and requires the node to have a mcollective server deamon running. The automation might be triggered remotely by the mcollective client using mcollective agents available on the Puppet node. The mcollective client should be notified of the puppetrun and might not be the same PuppetMaster, and a way to do this might be via a custom report extention that reports directly to the mcollective client. The benefit is that the monitoring can be managed via mcollective and there's a central point where data are collected and commands executed. The list of checks to be done on the client should, IMHO, remain on the Puppet client (mcollective server) itself (no need to have store configs for this) and maybe a specific agent might be done to retrieve and run from the mcollective client the list of checks to perform. Another point is how to organize and define the checks' list. Cucumber seems a nice and somehow "standard" way to define the checks logic, but could be also a plain execution of the different checks from a sort of wrapper script. The single checks could be nrpe commands and/or mcollective agents (I love the nettest one, incidentally). AFAIK there's nothing in the above examples that is particularly difficult or can't be done with existing tools, but I would like to introduce them seamlessly in my modules (using my monitoring abstraction classes). So, I wonder if someone is already doing similar checks, what's the approach they are following and what might be the evolution of Puppet under regarding these topics. Any further or related idea is welcomed, Alessandro Franceschi -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Prefixing syslog messages with client names
Thanks for great advice. The puppet clients are logging to the master, but I agree that it would be better for them to log to syslog. I've got an rsyslog master up and running, which all my linux servers log to, so I'll make use of that to extract the puppet related messages. - Kenneth On Tue, Oct 12, 2010 at 3:07 PM, Bruce Richardson wrote: > On Tue, Oct 12, 2010 at 02:27:51PM +0200, Kenneth Holter wrote: > > Hi. > > > > > > The puppetmaster is set up to log to syslog, which is working fine. The > > downside is that most of the log entries created by the puppetmaster does > > not indicate which puppet client that message if from. So basically I > have > > lots and lots of syslog entries created by the puppetmaster, but no way > of > > telling which client it references. > > Just to be clear, you are having your puppet clients tell the > puppestmaster what they are doing and then the master is logging that? > > > > > Is there any way to have the puppet master prefix each syslog message > with > > the name of the client the log message is for? > > I think it is better to have puppet clients logging to local syslog. > You can always configure your syslog daemon to replicate this to another > host (rsyslog or syslog-ng will both do this for you quite easily) or > have logwatch track it. The benefits of this are a) log redundancy, > b) you get to see what the client is doing even when the puppetmaster is > down (or not visible to the client) and c) less load on the puppetmaster > (logging can become a significant extra load if you have a large > network). > > -- > Bruce > > Explota!: miles de lemmings no pueden estar equivocados. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAky0XYYACgkQtkVqYTMBSwFu3QCdGuZauN7HtTk5dfVo8bYN3NeN > 5aUAn2ww1FAr4+WIokQhDwcCAhzbyHUT > =3vTw > -END PGP SIGNATURE- > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] client won't use remote file bucket
Hi all,
I'm having a stupid moment getting a remote file bucket working. My
client only file buckets locally, not remotely.
I have this site.pp:
*
filebucket { "main": server => "puppet" }
File { backup => "main" }
node 'default' {
include test
}
*
and this test module:
*
class test {
file { "/etc/sudoers":
source => "puppet:///modules/test/sudoers",
owner => "root",
group => "root",
mode => "0440",
ensure => present,
backup => "main",
}
}
*
$ puppetd --test --environment testing
...
info: FileBucket adding /etc/sudoers as {md5}
fee30f6b0672f6c174709249f37380d4
info: /Stage[main]/Test/File[/etc/sudoers]: Filebucketed /etc/sudoers
to main with sum fee30f6b0672f6c174709249f37380d4
notice: Finished catalog run in 0.49 seconds
According to the Apache logs (I use Passenger) the only PUT request
it's doing is for it's report:
10.44.222.42 - - [19/Oct/2010:16:18:26 +0100] "GET /testing/
catalog/..." 200 1439 "-" "-"
10.44.222.42 - - [19/Oct/2010:16:18:26 +0100] "GET /testing/
file_metadata/modules/test/sudoers HTTP/1.1" 200 307 "-" "-"
10.44.222.42 - - [19/Oct/2010:16:18:26 +0100] "GET /testing/
file_content/modules/test/sudoers HTTP/1.1" 200 1421 "-" "-"
10.44.222.42 - - [19/Oct/2010:16:18:27 +0100] "GET /testing/
file_content/modules/test/sudoers HTTP/1.1" 200 1421 "-" "-"
10.44.222.42 - - [19/Oct/2010:16:18:27 +0100] "GET /testing/
file_metadata/modules/test/sudoers HTTP/1.1" 200 307 "-" "-"
10.44.222.42 - - [19/Oct/2010:16:18:27 +0100] "PUT /testing/report/
puppet-test.fasthosts.net.uk HTTP/1.1" 200 35 "-" "-"
I've also stopped Apache and started up the Webrick Puppet Master,
same result, no file bucketed to the server.
Can someone point out what I've missed?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppetrun reports certificates were not trusted
Actually that problem were solved by simply rebooting all machines. After a restart suddenly it worked for all of them. >From time to time i experience however that single nodes produces following errors even if i havent run puppetrun very short before that run: "Host is already running finished with exit code 3" If i run puppetrun a second time than the same node does not report problems anymore. Does anybody know what is the background of that problem? Christian -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] use Tidy resource to clean puppet master reports
Hi list,
I was thinking of using a Tidy resource to clean up old reports on
puppet master servers but it doesn't seem to like it:
[r...@puppet-master-01 ~]# puppetd --test --noop
info: Retrieving plugin
info: Caching catalog for puppet-master-01.fasthosts.net.uk
err: /Stage[main]/Fh_puppet::Master/Tidy[/var/lib/puppet/reports/]:
Failed to generate additional resources using 'generate': Fileset
paths must be fully qualified
info: Applying configuration version '1287494784'
The manifest code that triggers this is:
tidy { "/var/lib/puppet/reports/":
age => "2w",
matches => "*.yaml",
recurse => true,
type=> "mtime",
}
I remember reading a post about Puppet and how it builds in memory
File resources when recursing through directories, so large amounts of
recursion is a bad idea. Would this be the same problem here? Right
now my reports directory is about 140 MB and around 2000 files. I can
easily replace the Tidy with an Exec but if someone in the know thinks
it's a bug I can submit a big report first.
Thanks,
-Luke
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: best practice for removing a module & maintained resources from a system ?
On Oct 18, 9:03 am, David Schmitt wrote: > Exactly. If done right, this can be achieved by using purging on the > proper directories (like /etc/http/conf.d) to keep away unmanaged > contents. For the most things this obviates the need for a ::no class > altogether. But purging makes my skin crawl :) Seriously, I worry that purging will end up removing something that I didn't intend. If that doesn't bother you, and if ensuring a config file is absent sufficiently addresses the issue, then purging indeed provides an even simpler solution. Via the "resources" meta-resource, you can also configure purging of resources such as users and packages. That would be unwise unless you have *ALL* resources of the chosen types under management, but for a rigorously Puppetized system it probably makes sense. Mine are not so thoroughly controlled. Regards, John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: unable to get puppet client to work
0.25.4 (Ubuntu repository) However, i got it working now. Seemed the reverse DNS was causing issues. Cheers, Marcel On 18 okt, 18:42, Mohit Chawla wrote: > Hi, > > What's the client version ? > > On Mon, Oct 18, 2010 at 9:36 PM, mar...@fearless.nl wrote: > > > > > Hi All, > > > first off, i'm new to puppet. I've started playing with it for a few > > days now and it seems to be perfectly matching my needs. > > > I've created two labs, one at home (working) and one in the office > > (not working). > > Now as you can gather, i would like some help on find the reason the > > the office-lab not to work. > > > The puppetmaster works as expected, starts good and without issue. > > > Starting it in debug mode says : > > > r...@master:/etc/puppet# puppetmasterd --no-daemonize -d -v > > debug: Failed to load library 'selinux' for feature 'selinux' > > debug: Failed to load library 'ldap' for feature 'ldap' > > debug: Puppet::Type::User::ProviderLdap: feature ldap is missing > > debug: Puppet::Type::User::ProviderPw: file pw does not exist > > debug: Puppet::Type::User::ProviderUser_role_add: file rolemod does > > not exist > > debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/ > > dscl does not exist > > debug: /File[/var/puppet/yaml]: Autorequiring File[/var/puppet] > > debug: /File[/etc/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/ > > puppet/ssl/certs] > > debug: /File[/etc/puppet/manifests]: Autorequiring File[/etc/puppet] > > debug: /File[/var/puppet/state]: Autorequiring File[/var/puppet] > > debug: /File[/var/puppet/facts]: Autorequiring File[/var/puppet] > > debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/ > > ssl] > > debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet] > > debug: /File[/etc/puppet/ssl/public_keys/master.pem]: Autorequiring > > File[/etc/puppet/ssl/public_keys] > > debug: /File[/var/puppet/log/masterhttp.log]: Autorequiring File[/var/ > > puppet/log] > > debug: /File[/etc/puppet/ssl/crl.pem]: Autorequiring File[/etc/puppet/ > > ssl] > > debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/ > > ssl] > > debug: /File[/var/puppet/rrd]: Autorequiring File[/var/puppet] > > debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring > > File[/etc/puppet/ssl] > > debug: /File[/var/puppet/bucket]: Autorequiring File[/var/puppet] > > debug: /File[/etc/puppet/auth.conf]: Autorequiring File[/etc/puppet] > > debug: /File[/var/puppet/reports]: Autorequiring File[/var/puppet] > > debug: /File[/etc/puppet/manifests/site.pp]: Autorequiring File[/etc/ > > puppet/manifests] > > debug: /File[/var/puppet/log]: Autorequiring File[/var/puppet] > > debug: /File[/var/puppet/lib]: Autorequiring File[/var/puppet] > > debug: /File[/etc/puppet/fileserver.conf]: Autorequiring File[/etc/ > > puppet] > > debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet] > > debug: /File[/etc/puppet/ssl/certs/master.pem]: Autorequiring File[/ > > etc/puppet/ssl/certs] > > debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/ > > puppet/ssl] > > debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/ > > puppet/ssl] > > debug: /File[/etc/puppet/ssl/private_keys/master.pem]: Autorequiring > > File[/etc/puppet/ssl/private_keys] > > debug: /File[/var/run/puppetmasterd.pid]: Autorequiring File[/var/run] > > debug: Finishing transaction -610961228 with 0 changes > > debug: /File[/etc/puppet/ssl/ca/private]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/serial]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/private/ca.pass]: Autorequiring File[/ > > etc/puppet/ssl/ca/private] > > debug: /File[/etc/puppet/ssl/ca/requests]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/ca_crl.pem]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/ca_crt.pem]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/inventory.txt]: Autorequiring File[/ > > etc/puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/ca_key.pem]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/signed]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: /File[/etc/puppet/ssl/ca/ca_pub.pem]: Autorequiring File[/etc/ > > puppet/ssl/ca] > > debug: Finishing transaction -611217558 with 0 changes > > debug: Using cached certificate for ca, good until Fri Oct 16 14:58:50 > > UTC 2015 > > debug: Using cached certificate for ca, good until Fri Oct 16 14:58:50 > > UTC 2015 > > debug: Using cached certificate for master, good until Fri Oct 16 > > 14:58:50 UTC 2015 > > notice: Starting Puppet server version 0.25.4 > > > Which seems good to me. > > > Now when i start a client, this happens : > > > r...@ubuntu:~# puppetd --no-daemonize --verbose --server master --fqdn > > ubuntu.lab --waitforcert 60 -o > > err: Could not retrieve catalog from remote server: Error 403 on > > SERVER: Forbid
Re: [Puppet Users] Re: Negate or uninclude a class
On 10/18/2010 05:24 PM, Bruce Richardson wrote:
> On Mon, Oct 18, 2010 at 07:20:10AM -0700, jcbollinger wrote:
>>
>> On Oct 18, 4:38 am, Bruce Richardson wrote:
>>> No, you can't uninclude a class.
>>
>> Right.
>>
Is the only way to do this to inherit the base class and override all
it's resources to do the equivalent of "ensure => absent", then
something like "if (tagged(class)) { include undo-subclass } " where
needed?
>>
>> [...]
>>
>>> You *could* do it with overrides but only If you were using a define
>>> within your base class for part of the setup and that define took a
>>> parameter which told it whether to include the ldap class.
>>
>> You could write it that way, but Puppet's subclassing feature is
>> designed precisely so that you don't need to do so.
>
> Um, I completely disagree with you and the rest of your post actually
> backs this up. Class inheritence *only* makes sense if you want to
> override the properties of resources. The OP wants not to include a
> whole class; what you're telling him to do is not uninclude the class,
> but to try and override properties in every resource owned by the class,
> so as to make the class effectively do nothing. There are any number of
> reasons why that's not a smart thing to do, but here are several that
> occur to me immediately.
>
> 1. If the resources in the ldap::client class change, the
> ldap::client::disabled will have to be changed to match. This
> just begs to be a source of error.
>
> 2. The structure of the ldap::client class and it's resources may
> well have to be distorted to fit this arrangement. Some resources
> would have to be set up quite carefully so that they could be
> "negated".
>
> 3. What do you do about virtual resources that are realized in the
> parent class? You can't unrealize them and if you override their
> properties, you may well conflict with other modules or classes which
> use them. #
>
> 4. What do you do about any other classes that are included in the
> parent class? Are you going to include "::disabled" versions of
> those in the ldap::client::disabled class? What if those classes
> are included elsewhere?
>
> Your exmaple cannot achieve the same effect as not including a class;
> the empty files you'd litter the filesystem with is only one example.
> Forcibly negating everything in a class is not the same as not including
> it. Why not just not include it?
>
>> For example, although Bruce's main suggestion could be used if for
>> some reason it were important to avoid subclasses, really in that case
>> something akin to his define-based suggestion (but without subclasses)
>> would be better. That way, if the LDAP client somehow gets turned on
>> on your LDAP server, then Puppet will turn it back off. Unconfigured
>> means "I don't care"; it must not be confused with "off". The
>> subclass usage pattern above achieves the same thing with no
>> conditional inclusions and no define, plus it's safe against inclusion
>> of "ldap::client" by other parts of the manifest.
>
> I'm sorry, but I think you are quite wrong and your recommendations are
> very unwise. I have no objection to class inheritance at all, although
> the way it works in puppet is often misunderstoon and it is often
> overused as a result. Your proposed example is definitely not a good
> use of class inheritance.
>
> "ssh::server::disabled" makes sense, because that's done by overriding
> the properties of an existing service resource to make sure it's
> disabled. ldap::client::disabled does not make sense; the OP wants the
> actions in ldap::client not to be applied, not to be differently
> applied.
>
> By far the simplest and safest way not to include a whole class is the
> "if $ldap_enabled { include ldap::client }" method; it has no bad side
> effects, it works no matter how the internals of the ldap::client
> change, it's a tiny bit of code.
>
Hi Bruce,
I was glad for John's comment on your answer because it mirrored my
sentiment exactly, and I in turn disagree with most of what you've
written here.
Subclasses that effectively disable a class are a sound concept. How
this has to be achieved in any specific case can be somewhat
mind-boggling, but the variable approach has severe limitations of its own.
1. Where is the variable set? You have probably no problem when using
external node definition, but not everybody does. You cannot define the
variable in an arbitrary part of your manifest, because you can be
afflicted by both ordering and scoping issues.
2. The concept of dynamic scoping is going away in future versions (at
least that is what seems to be a community consensus). Again, if you can
globally assign the variable value to your node, this is not a problem.
But if you want to for every node that includes class B to automatically
not include class A, you're out of luck (this is true in many cases
today already, beca
Re: [Puppet Users] setting type defaults in some classes
On Tue, Oct 19, 2010 at 11:32:26AM +0200, Arnau Bria wrote:
> I don't remember from where I took the idea... but seems that I chose
> wrong place :-) What do you recommend me? any doc to follow?
Unfortunately, I don't think there is great documentation out there; the
core development team is too busy and so are most of the users.
Documentation lags behind. I'd love to add better documentation to
Puppet but I have a very busy and stressful job, so I fail too. But in
any case...
> > the included class had better be in the file found by the
> > autoloader). I hope that's a little clearer.
>
> Reading your answer (and if I thought a little more about it before), my
> question
> could be answered by myself. As you say import "inserts" code, so
> having 2 diff defaults in 2 diff sites does not make much sense, or does not
> behave as I wish.
Great! Now that you understand better how imports and includes work,
you're answering your own questions. I bet you can work out a better
way of laying out your manifests for yourself.
The best advice I can give you is to work with the way puppet
module/class autoloading works, not against it.
>
> If I redefine File defaults in comuting_bacula (in the class, not
> module) it's evaluted and it's more important:
>
> class computing_bacula {
> File { mode => 755 }
> }
> File { 'kaka' }
>
> on client:
> notice: /Stage[main]/Computing_bacula/File[kaka]/mode: mode changed '666' to
> '755'
>
>
> So class defaults "are more important" than site dfaults.
If there is a conflict between an already declared default and a new
default, the new default wins. If there is no conflict, they are added
together. If you go back to my example, I set a default of "ensure =
file" at the top level. Because none of the later defaults had an
"ensure" parameter, all files inherited that default. I also set "mode
= 750" at the top level, but in some places I later declared "mode"
again. In such cases, the declaration in the most immediate scope
always wins.
--
Bruce
What would Edward Woodward do?
signature.asc
Description: Digital signature
Re: [Puppet Users] setting type defaults in some classes
On Tue, 19 Oct 2010 00:07:50 +0100
Bruce Richardson wrote:
Hi Bruce,
I'd like to thanks the time you take for answering my question.
> > ~puppet/manifests/site1.pp
> > /services/
> > /SERA/site2.pp
> > /modules2
> > /SERB/site3.pp
> > /modules3
> >
> > -site1.pp defines some defaults and includes services/SERA/site2.pp
> > and service/SERB/site3.pp
> > -site2.pp defines its own defaults for modules2
> > -site3.pp defines its own defaults for modules3
>
> Do you mean "imports", or do you really mean "includes"?
we do imports, no includes. Sorry.
> I suppose you must really mean "include"; if you were importing those
> manifests and had defaults defined inside them, puppet would complain
> that you were defining defaults twice in the same scope and refuse to
> proceed. Unless the defaults are wrapped within classes.
Well, unfortunately for us no resource overwrite happened so we saw no
error. If overwriting defaults, and as you well say, puppet complains.
(We had, i.e., default service => path in site1.pp and ensure => enable
in site2.pp).
> Your layout looks a little crazy. Why are you calling them all site1,
> site2, site3.pp?
Just following puppet "schema", nothing else. It's for our commodity:
Diff SER are managed by diff pepople, so each one can modify its own
"site" and import its own modules (They also have its own
nodes.pp). If we want to add a project, we only have to add new SER with
its own site, node, ... and then "import" new site/node in site1/node1.
Is like having a big puppet with all modules/classes available
everywhere but divided in sub-trees.
I don't remember from where I took the idea... but seems that I chose
wrong place :-) What do you recommend me? any doc to follow?
[...]
> In any case, once puppet
> is given a starting manifest, what happens next is entirely down to
> your code. If you import code, it is "inserted" in place and treated
> as if you had typed the code directly into the file at the point
> where the import line is found. If you import code which contains a
> class, the class will not be evaluated until it is explicitly
> included. If you include a class that is not already in the code
> that has been read, puppet will try to autoload it (that is, it will
> look in some standard locations for manifests with specific names and
> *import* them if it finds them, then try and include the class - so
> the included class had better be in the file found by the
> autoloader). I hope that's a little clearer.
Reading your answer (and if I thought a little more about it before), my
question
could be answered by myself. As you say import "inserts" code, so
having 2 diff defaults in 2 diff sites does not make much sense, or does not
behave as I wish.
> Are you actually clear about the difference between importing and
> including? Which are you really doing there? Oh, and did you base
> that layout at all on the "style guidelines" from the wiki? Because I
> personally think those are terrible (sorry to whomever wrote that,
> but I really think it's an overcomplicated and undocumented mess, that
> recommended layout).
Well, after my question and your answers, we could say that not
much :-) Or basic idea.
I already asked it some time ago:
http://www.mail-archive.com/puppet-users@googlegroups.com/msg04826.html
and read some doc in puppet site.
> Hmm. I think I spotted something. What do you mean "site2.pp defines
> its own defaults for modules2"?
At this point, that conf has no sense.
> Is it posssible that site2.pp imports modules2?
> And that you have a bunch of classes defined in site2.pp?
Yes, it does. I.e we define classes under
modules2/mod1/manifests/init.pp
> Because if that's the case, I have to tell you that the defaults in
> site2.pp are irrelevant. What counts is what the defaults are in the
> scope within which the classes are *included*.
Mmmm... I'm not sure if I got you, but they're important:
site1.pp:
File { mode=> 666, }
services/workernode/modules/computing_bacula/manifests/init.pp
file { 'kaka':
name=> '/root/kaka',
ensure => present;
}
On client:
notice: /Stage[main]/Computing_bacula/File[kaka]/ensure: created
# ls -lsa /root/kaka
0 -rw-rw-rw- 1 root root 0 Oct 19 11:15 /root/kaka
If I redefine File defaults in comuting_bacula (in the class, not
module) it's evaluted and it's more important:
class computing_bacula {
File { mode => 755 }
}
File { 'kaka' }
on client:
notice: /Stage[main]/Computing_bacula/File[kaka]/mode: mode changed '666' to
'755'
So class defaults "are more important" than site dfaults.
> I'm only guessing about your code, though. I don't understand your
> layout and how the different parts of it are linked.
So, maybe now you understand my original question :-) Maybe it's because my
wrong use of imp
[Puppet Users] Re: Augeas type to edit/append to /etc/pam.d/sshd
Just for the info, I've gotten the answer at why lines like these
error:
set *[module = 'pam_mkhomedir.so']/type session
or a similar example for /etc/hosts:
set /files/etc/hosts/*/ipaddr[.='10.1.1.1'] 10.1.1.1
To quote from the augeas-devel list: "The issue is where there is no
node matching /files/etc/hosts/*/ipaddr[.='10.1.1.1'], Augeas tries to
create one, but it doesn't know what to use for '*'."
To handle the cases where you don't know if a line containing an IP
address exists or not, you need to use two Augeas types; one to fix an
existing entry and one to add an entry if it doesn't exist.
There's a feature request to support conditionals in the Augeas type
here: http://projects.puppetlabs.com/issues/2696
On Oct 5, 12:21 pm, "luke.bigum" wrote:
> Tim,
>
> Thanks a lot, I never would have thought of trying to cludge Augeas
> like that. Your specific insert line didn't work for my environment,
> what did work was a slight variation:
>
> "ins 100 after *[last()]"
>
> I'll still try chase up the Augeas people to see if there is a more
> elegant solution, but for now that works great and should translate to
> all all Augeas lenses that present nodes as array indexes.
>
> Thanks,
>
> -Luke
>
> On Oct 5, 11:43 am, Tim Sharpe wrote:
>
> > Hi Luke,
>
> > I do something similar for a different module, give the following a try:
>
> > augeas { "mod_mkhomedir_for_pam_sshd":
> > context => "/files/etc/pam.d/sshd",
> > changes => ["ins 100 before *",
> > "set 100/type session",
> > "set 100/control required",
> > "set 100/module pam_mkhomedir.so",
> > "set 100/argument umask=0022"],
> > onlyif => "match
> > *[type='session'][module='pam_mkhomedir.so'][argument='umask=0022']
> > size == 0"
>
> > }
>
> > Cheers,
> > Tim
>
> > On 5 October 2010 03:00,luke.bigum wrote:
>
> > > Hi all,
>
> > > I'm trying to do something that should be pretty simple but can't
> > > figure it out.
>
> > > I want to append a line to /etc/pam.d/sshd if a line with a certain
> > > module doesn't exist.
>
> > > What I would like to work is this:
>
> > > augeas { sshd_pam_mkhomedir:
> > > context => "/files/etc/pam.d/sshd",
> > > changes => [
> > > "set *[module = 'pam_mkhomedir.so']/type session",
> > > "set *[module = 'pam_mkhomedir.so']/control required",
> > > "set *[module = 'pam_mkhomedir.so']/module pam_mkhomedir.so",
> > > "set *[module = 'pam_mkhomedir.so']/argument[1] umask=0022",
> > > ],
> > > }
>
> > > That "*[module = foo]" fails to match and create a new line, even in
> > > augtool. This doesn't work either:
>
> > > augtool> set /files/etc/pam.d/sshd/*[last()+1]/type session
> > > Failed
>
> > > Nor can I get an insert to work, as to do that I'd need to know the
> > > number of entries that already exist in the file in order to create
> > > the next one.
>
> > > If no one's already got a solution to this I'll have to ask on augeas-
> > > devel.
>
> > > Thanks,
>
> > > -Luke
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Puppet Users" group.
> > > To post to this group, send email to puppet-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > puppet-users+unsubscr...@googlegroups.com.
> > > For more options, visit this group
> > > athttp://groups.google.com/group/puppet-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Application Server Deployment
hello Bruce, I was wondering is SmartFrog better than Puppet or are they both of equal level. If u have some examples could u pls send them to me.. i am trying to learn everything from scratch and learning thru examples will make my learning fast. thank u and regards ajinkya On Mon, Oct 18, 2010 at 6:10 PM, Bruce Richardson wrote: > On Mon, Oct 18, 2010 at 01:19:41AM -0700, ajax wrote: > > Hello all, > > > > I wanted to know can i deploy Application Severs like JOnAS (java) > > using Puppet from the server. > > Absolutely, you can. Puppet can deploy it as easily as any other > applicaton. Where things become interesting is when you have to decide > whether to deploy and configure individual Java applications to JOnAS, > or how much of the configuration is done by puppet, how much through the > JOnAS console. People have very different philosphical approaches to > that. Nice to have the choice, though. > > > -- > Bruce > > What would Edward Woodward do? > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- Thank you and Regards Ajinkya Prabhune -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
