[Puppet Users] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
On Oct 19, 10:52 pm, Nicolas Szalay nsza...@qualigaz.com wrote: - Al @ Lab42 lab42...@gmail.com 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] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
- Al @ Lab42 lab42...@gmail.com 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.
Re: [Puppet Users] Automating infrastructure tests on Puppet nodes after a puppetrun
On Tuesday 19 Oct 2010 21:52:37 Nicolas Szalay wrote: - Al @ Lab42 lab42...@gmail.com 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 OK, so we do this slightly differently however it might help... 1) All our manifests are stored in Git 2) A Git update forces Hudson to run a build 3) The Build process performs the following steps: * Checkout the latest version of the manifest into the staging server's puppet-module-path * Start a virtual server of the defined type using cucumber-vhost[0] * Use puppet to deploy the latest staging versions of the manifests to the virtual-server * run cucumber tests (using webrat for webservices and SMTP/IMAP libraries to test sending/delivery of email) against the service/facility that is contained in the manifests we are testing * Report back on the results of those tests * Destroy the virtual server This means that all of our manifests are fully tested before they go near our production system and we can be confident (although obviously this is only as good as the tests that we write!) that when we merge from staging into master the changes that are rolled out will work correctly. I've not gone down the cucumber-puppet root as I'm not 100% sure how it works and how to write stories correctly so if anyone can point me at a good resource on this, I'd be very appreciative! Hope that helps, Matt -- 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: Automating infrastructure tests on Puppet nodes after a puppetrun
Le mardi 19 octobre 2010 à 23:49 -0700, Al @ Lab42 a écrit : Generally yes. IMHO, monitoring needs a refresh to cope with the new way servers are operated built. This is a larger topic that this single thread :) 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. Wouldn't this kind of instant monitoring be too overwhelming ? I mean : if you have 500 hosts, checking every 30 minutes you would get a central service server checked every 3.6s. How about log correlation, it's not perfect but it can be an acceptable intermediate solution (damn splunk and its crazy pricing) Nico. signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Puppet Users] how to set Ruby path?
On Oct 20, 2010, at 2:13 AM, bobics wrote: 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). You can use an abosulte path to ruby to run puppet: % /usr/bin/ruby /usr/sbin/puppetd All the best, Sandor Szücs -- -- 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
Not that I've been able to see, James, though I'd put money on that I've probably missed something so ridiculously simple that I can't see it. I've attached the client and Webrick master debug logs - the Master's Report http error at the end can be ignored, it's because Apache is shut down on the box (Puppet Master and Dashboard are the same server in this case). I've also pasted master and client configs in case it helps. As the logs show, the puppet clients *say* they are filebucketing to 'main', but it only ends up in the local /var/lib/puppet/clientbucket/ and not the master's /var/lib/puppet/bucket/. Even the Puppet Master, which is also a Puppet client, only filebuckets into the clientbucket directory. [r...@puppet-test ~]# grep -v '#' /etc/puppet/puppet.conf | egrep -v '^ $' [main] logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl [agent] environment = testing classfile = $vardir/classes.txt localconfig = $vardir/localconfig report = true reportserver = puppet splay = true runinterval = 1200 [r...@puppet-master-01 puppet]# grep -v '#' /etc/puppet/puppet.conf | egrep -v '^$' [main] logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl tagmap = /etc/puppet/tagmail.conf pluginsync = true factpath = $vardir/lib/facter [agent] environment = production classfile = $vardir/classes.txt localconfig = $vardir/localconfig report = true reportserver = puppet splay = true runinterval = 1200 [master] certname = puppet ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY modulepath = /var/lib/puppet/modules:/etc/puppet/modules reports = tagmail, http, store reporturl = http://localhost:3000/reports [production] manifest = /etc/puppet/conf/production/manifests/site.pp modulepath = /etc/puppet/conf/production/modules [development] manifest = /etc/puppet/conf/development/manifests/site.pp modulepath = /etc/puppet/conf/development/modules [testing] manifest = /etc/puppet/conf/testing/manifests/site.pp modulepath = /etc/puppet/conf/testing/modules [r...@puppet-test ~]# puppetd --test --debug --trace --verbose debug: Puppet::Type::User::ProviderLdap: true value when expecting false debug: Puppet::Type::User::ProviderUser_role_add: file rolemod does not exist debug: Puppet::Type::User::ProviderPw: file pw does not exist debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/ dscl does not exist debug: Puppet::Type::File::ProviderMicrosoft_windows: feature microsoft_windows is missing debug: Failed to load library 'ldap' for feature 'ldap' debug: /File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/ puppet] debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/ var/lib/puppet/ssl/certs] debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/var/lib/puppet/ssl/public_keys/puppet- test.fasthosts.net.uk.pem]: Autorequiring File[/var/lib/puppet/ssl/ public_keys] debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring File[/var/lib/ puppet/ssl] debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/ lib/puppet/state] debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/ puppet] debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet] debug: /File[/var/lib/puppet/ssl/private_keys/puppet- test.fasthosts.net.uk.pem]: Autorequiring File[/var/lib/puppet/ssl/ private_keys] debug: /File[/var/lib/puppet/ssl/certs/puppet- test.fasthosts.net.uk.pem]: Autorequiring File[/var/lib/puppet/ssl/ certs] debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/ puppet] debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/ puppet/ssl] debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/ var/lib/puppet/state] debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/ lib/puppet] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ puppet] debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring File[/var/ lib/puppet/ssl] debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/ var/lib/puppet/ssl] debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/ puppet] debug: /File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/ puppet/ssl] debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet] debug: Finishing transaction 23911437109040 debug: /File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/ puppet/ssl] debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/ssl/public_keys/puppet- test.fasthosts.net.uk.pem]: Autorequiring File[/var/lib/puppet/ssl/ public_keys] debug: /File[/var/lib/puppet/ssl/certs/puppet- test.fasthosts.net.uk.pem]: Autorequiring
[Puppet Users] Send diff in tagmail report ?
Is it possible to configure puppet to send a diff of old/new files in the tagmail reports when it's changing files ? Or has someone made a solution for creating such a report against the clientbucket ? -jf -- 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
* Matt Wallace [2010-10-20]: I've not gone down the cucumber-puppet root as I'm not 100% sure how it works and how to write stories correctly so if anyone can point me at a good resource on this, I'd be very appreciative! I have put up some documentation at http://projects.puppetlabs.com/projects/cucumber-puppet/wiki If that doesn't get you started, feel free to ask here or email me directly. I would be glad to update the documentation in case anything is unclear. cheers, Nikolay -- It's all part of my Can't-Do approach to life. Wally -- 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] stages examples/advices
On 10/18/2010 6:14 PM, Hunter Haugen wrote:
so you could do this:
class orden {
stage { [ 'repos', 'os', 'gLite', 'post' ]: }
Stage['repos'] - Stage['os'] - Stage['main'] - Stage['gLite'] -
Stage['post']
}
A style question: wouldn't it be preferable to write it like this:
class orden {
stage { 'repos': } - stage { 'os': } - stage { 'main': } - stage
{ 'gLite': } - stage { 'post': }
}
Best Regards, David
--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999
FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg
--
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: Automating infrastructure tests on Puppet nodes after a puppetrun
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I would suggest taking a look at OpenSCAP and the SCAP initiative led by NIST. It is an Open Standard and to me, the concepts act as the validation side of Puppet enforcement. http://www.open-scap.org/page/Main_Page http://scap.nist.gov/revision/index.html http://oval.mitre.org/ Thanks, Trevor On 10/20/2010 02:21 AM, Al @ Lab42 wrote: On Oct 19, 10:52 pm, Nicolas Szalay nsza...@qualigaz.com wrote: - Al @ Lab42 lab42...@gmail.com 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 - -- Trevor Vaughan Vice President, Onyx Point, Inc. email: tvaug...@onyxpoint.com phone: 410-541-ONYX (6699) pgp: 0x6C701E94 - -- This account not approved for unencrypted sensitive information -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJMvsqEAAoJECNCGV1OLcypn2QIAJXxNqPMXPLfNukjVRzsiogB DeDMKxOk1FsgBLd3KHBOsWTupDD3Tiv7t+NoQS+FACRq9ok2xuVyLUfGMYlUsswI yBiVawgWIKJAun3IVPoQne8eG2CIyCDnLVTyMjbDAKfJjEwTtSwzetokTEJbVakk 0ygBCnv6Lz7Hz6ghMNU4QyosMEjkeRRumwqEJCULBpU2mNY5ggcIgudoY6GwRQhd YX3wEelm0m3PvohieF4Rh9I5fx0hFMsFvWeNXCPRE1vzRea3Af/gRvROqHbywrl0 tf0iTsPEF1hMsd/+GLoSOvA+qzGfPq+zLHeeGbJ9sE2qKCKA3S7saRfl7/uOHlA= =oBVD -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. attachment: tvaughan.vcf
[Puppet Users] Re: ANNOUNCE: Puppet Dashboard 1.0.4 released!
I get the following error: Database isn't the current migration version: expected 20100726070117, got 20100916183948 You must either run 'rake db:migrate' or set environmental variable NO_MIGRATION_CHECK I upgraded from 1.0.4rc2 and did run 'rake RAILS_ENV=production db:migrate' before restarting apache. On Oct 20, 1:59 am, James Turnbull ja...@puppetlabs.com wrote: 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.mark... 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 -Uvhhttp://yum.puppetlabs.com/base/puppetlabs-repo-3.0-2.noarch.rpm;\ rpm -Uvhhttp://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.no... \ 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: debhttp://apt.puppetlabs.com/ubuntulucid main deb-srchttp://apt.puppetlabs.com/ubuntulucid 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
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On Mon, Oct 18, 2010 at 9:13 AM, jcbollinger john.bollin...@stjude.org wrote: I'm guessing you mean you have written sub-*classes* to do that job. That is indeed the Puppet way to do it, and I don't find it at all ridiculous. As a puppet newcomer, that is a bit surprising, and IMO unreasonable. Imagine you are joining a puppet-using company. To remove a class from a server you now need to know all the files ever installed or managed by that class, since puppet started to be used there. There is no place (in puppet) to query that info! Hopefully some SCM was used, and used consistently. And you have to review by hand each revision. Joy! Compare/contrast this to what package mgmt tools do: they keep a small DB of what files they are tracking for each package on a given machine. A new version of the package needs only declare what files it has. The pkg manager will helpfully remove any stale files. From the PoV of the packager... I don't need to know what files any and all releases of this package installed -- it'd be impossible to know anyway. I don't need to remove any possible file ever installed by this package. Puppet manages many resource types, so this isn't trivial. For some resource types what to do won't be super clear. Puppet (currently doesn't, but ) should track what it manages, and help us remove it when appropriate. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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: best practice for removing a module maintained resources from a system ?
On Oct 20, 2010, at 8:00 AM, Martin Langhoff wrote: On Mon, Oct 18, 2010 at 9:13 AM, jcbollinger john.bollin...@stjude.org wrote: I'm guessing you mean you have written sub-*classes* to do that job. That is indeed the Puppet way to do it, and I don't find it at all ridiculous. As a puppet newcomer, that is a bit surprising, and IMO unreasonable. I wouldn't call it unreasonable. I would call it lack of a really cool feature. Imagine you are joining a puppet-using company. To remove a class from a server you now need to know all the files ever installed or managed by that class, since puppet started to be used there. Except if you look through the definitions in the class it shouldn't be too manually write rules that do the opposite. Second, you don't need to do this for config files in directories managed with purge. Third, if you're in a hurry, you don't actually need to reverse every step. You only need to disable anything that's active. This isn't a best practice, but it does work if you're careful. There is no place (in puppet) to query that info! Hopefully some SCM was used, and used consistently. And you have to review by hand each revision. Joy! Compare/contrast this to what package mgmt tools do: they keep a small DB of what files they are tracking for each package on a given machine. A new version of the package needs only declare what files it has. The pkg manager will helpfully remove any stale files. From the PoV of the packager... I don't need to know what files any and all releases of this package installed -- it'd be impossible to know anyway. I don't need to remove any possible file ever installed by this package. Puppet manages many resource types, so this isn't trivial. For some resource types what to do won't be super clear. I would go farther and say that it could be very very unclear. Exec is a trivial example and is trivial to fix by adding another parameter. A much nastier example is File. I've been managing a config file. The file existed before and File replaces it. Later the file is replaced by something other than Puppet. File dutifully replaces the file again. Which file should puppet restore? Puppet (currently doesn't, but ) should track what it manages, and help us remove it when appropriate. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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. -- 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] show dependency tree?
Is there a way to view the resource relationship tree for a class (or all classes)? I'd like an easy way for our admins to see things like what classes refer to the same resource, which classes require another class, etc. thanks -- 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] nagios_service types and name
On Wed, Oct 20, 2010 at 05:16:39PM +0100, Bruce Richardson wrote:
desired behaviour, why does the nagios_service type have use and
register parameters, because they are useless without the ability to
attach names to services in the generated nagios config.
Well, use is still functional, because I can always put service
templates into puppet templates or just statically copied files, rather
than using the nagios_service resource. But setting register = 0 on
a nagios_service type is pointless if you can't reuse the resulting
object, because it has no name.
Is it really the case that services, alone out of all the nagios object
types, can't generate object templates from the corresponding puppet
type? What I want to do is this kind of thing:
nagios_service { 'generic-service':
whatever
register = '0'
}
nagios_service { 'ping-service':
use = 'generic-service',
service_description = 'Ping'
check_command = 'check_ping!100.0,20%!500.0,60%',
register = '0'
}
and then in some role class...
@@nagios_service { ping_$fqdn:
use = 'ping-service'
hostname = $fqdn
register = '1'
}
But, unless I'm missing something, I can only do that by creating a file
containing nagios service templates via some other route.
--
Bruce
I must admit that the existence of Disneyland (which I know is real)
proves that we are not living in Judea in AD 50. -- Philip K. Dick
--
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 19, 6:04 pm, Bruce Richardson itsbr...@workshy.org wrote: [...] I agree with you about the importance of state, but in that scenario, to me, not being an LDAP client is the basic state. After much consideration, I think a great deal of this debate hinges on that definition. It is perfectly reasonable, but not exclusively so. For instance, my basic state is for systems to be NIS clients. It seems most reasonable to me for the basic state to provide those configuration details from which few of my systems deviate. The OP's, at present, is for systems to be LDAP clients. 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. I don't quite understand that. How does your configuration protect the basic state of a system without including classes? You could use global resources, but then those could not be overridden. I suspect that instead you have one or more core classes that you include on every node to establish and maintain the basic state; that seems consistent with your further comments. Particular nodes then include *other* classes to modify or extend. [...] 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. I think you're saying that you would implement ldap::client itself using subclassing if (and only if) it needs to alter anything in the core. There's merit to that, and doing it that way could indeed have exactly the results you describe. No further subclass would be required. But how does this apply to the OP? His current basic state is for systems to be LDAP clients. That's not what you would choose, but if he retains that choice, then does not your approach call for subclassing where a node must not be an LDAP client? Such nodes would then include ldap::client::disabled to override the base, and dropping that class would restore base functionality, just as you recommend. In all likelihood, such a subclass could be very slim: it probably needs to override only a small number of resources to disable the client (maybe just /etc/nsswitch.conf); it shouldn't need to completely counter everything in ldap::client. 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. I'm curious: what types of resources do you purge, in what contexts? Your configuration philosophy seems similar to mine in that you don't try to manage every system detail, but that rather limits the available scope for purging, doesn't it? [...] 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. Much then depends on the chosen measure of complexity. I think you mean to judge by some measure of distance between the target state and a base reference state, which I take to be your basic / clean state. Your recommendations then make good sense when you stipulate the existance of a default state to fall back on, especially when coupled with purging to clean up potentially troublesome unwanted resources (thanks for those clarifications). How that applies to the OP's case is a different question, however. If he continues to rely on a base state in which the LDAP client is enabled, then overriding that state to disable the client leads to a more complex state (by the above standard). As I said at the beginning, much seems to hinge on the choice of base state. Our positions now seem much closer than they originally did. I won't argue over how a system's base state should be constituted -- that's too subjective -- and otherwise we seem largely to agree. Overall, my main objection to your original response was about your claim that a subclass-based solution would require use of defines and conditionals. You seem to have backed off on that, so I think we're good. Cheers, 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
Re: [Puppet Users] ANNOUNCE: Puppet Dashboard 1.0.4 released!
On 20.10.2010, at 01:59, James Turnbull wrote: 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/). Updated from version 1.0.3 using the provided rpm package without any issues. Dashboard is running on apache with mod_passenger on RHEL 5. The Performance increase is incredible ! Dashboard now loads very fast with approx 50 nodes with reports of the last 30 days. Thank you. Martin -- 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] puppetd 0.25.4 with puppetmaster 0.24.8?
Our puppetmaster runs 0.24.8 on Ubuntu 9.10. Our clients are either Ubuntu 9.10 or Ubuntu 8.04. We've just brought up our first Ubuntu 10.04 machine. This machine installs puppetd 0.25.4. The Ubuntu 10.04 machine can't seem to present it's certificate request properly. In my masterhttp.log, I see [2010-10-20 13:09:06] 174-143-141-55.static.cloud-ips.com - - [20/Oct/2010:13:09:05 CDT] PUT /production/certificate_request/edglucid1.newhostingaccount.net HTTP/1.1 404 359 getting a 404. Also [2010-10-20 13:24:52] 174-143-141-55.static.cloud-ips.com - - [20/Oct/2010:13:24:52 CDT] GET /production/certificate/ca HTTP/1.1 404 322 There is no certificate pending to sign. My command line on the client side was /usr/sbin/puppetd --no-daemonize --verbose --onetime --server=xxx --fqdn=edglucid1.newhostingaccount.net Am I hitting a version incompatibility, and is there any hope for this other than installing a newer puppetmaster, from source (since Ubuntu 9.10 doesn't provide 0.25) or upgrading the puppetmaster server to Ubuntu 10.04? -- 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] show dependency tree?
You can do that by enabling graphs to be generated, in puppet.conf or as an argument to the client daemon. On Wed, Oct 20, 2010 at 9:34 PM, jb jeffb...@gmail.com wrote: Is there a way to view the resource relationship tree for a class (or all classes)? I'd like an easy way for our admins to see things like what classes refer to the same resource, which classes require another class, etc. thanks -- 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://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] puppetd 0.25.4 with puppetmaster 0.24.8?
If the upgrades are not gonna break your network, you'd better upgrade. Also you'd wanna have the masters upgraded first rather than the clients. But still you can through the release notes for both the versions and see if you can work out a solution. On Thu, Oct 21, 2010 at 12:02 AM, Ed Greenberg e...@greenberg.org wrote: Our puppetmaster runs 0.24.8 on Ubuntu 9.10. Our clients are either Ubuntu 9.10 or Ubuntu 8.04. We've just brought up our first Ubuntu 10.04 machine. This machine installs puppetd 0.25.4. The Ubuntu 10.04 machine can't seem to present it's certificate request properly. In my masterhttp.log, I see [2010-10-20 13:09:06] 174-143-141-55.static.cloud-ips.com - - [20/Oct/2010:13:09:05 CDT] PUT /production/certificate_request/ edglucid1.newhostingaccount.net HTTP/1.1 404 359 getting a 404. Also [2010-10-20 13:24:52] 174-143-141-55.static.cloud-ips.com - - [20/Oct/2010:13:24:52 CDT] GET /production/certificate/ca HTTP/1.1 404 322 There is no certificate pending to sign. My command line on the client side was /usr/sbin/puppetd --no-daemonize --verbose --onetime --server=xxx --fqdn= edglucid1.newhostingaccount.net Am I hitting a version incompatibility, and is there any hope for this other than installing a newer puppetmaster, from source (since Ubuntu 9.10 doesn't provide 0.25) or upgrading the puppetmaster server to Ubuntu 10.04? -- 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://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] Re: best practice for removing a module maintained resources from a system ?
On Wed, Oct 20, 2010 at 10:26 PM, Martin Langhoff martin.langh...@gmail.com wrote: Pretty fundamental feature :-) You don't have random scripts doing random business. If the puppet modules have been written nicely, I don't see any reason to be unable to go through them once, understand the structure, and work from that point. Even if they are not written nicely, you still have all the information in there, a bit of cleanup and you're on your way. You can have test runs, parse tests and all, just to know the state of the modules. Except that some definitions may be gone. That's what worries me. Sure I can read the pp files as they are today. That's probably true for any tool or method. Unless it was in version control. -- 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: best practice for removing a module maintained resources from a system ?
On Wed, Oct 20, 2010 at 3:00 PM, Mohit Chawla mohit.chawla.bin...@gmail.com wrote: Except that some definitions may be gone. That's what worries me. Sure I can read the pp files as they are today. That's probably true for any tool or method. Unless it was in version control. Not true of packages under any modern packaging system, as per the example given. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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] Nigel Kersten has started at Puppet Labs
Hi all, I think many people know this already, but Nigel Kersten has officially joined us (started today) as product manager. His first job will be figuring out exactly what that means. In general, however, Nigel's main job will be making sure that we as a company are working on the right priorities - synthesizing input from all of you, our customers, me, our developers, and anyone else, and then turning that into a plan for continuing to produce great product. I'm very excited at Nigel joining the company, as he brings real-world experience at running the largest known Puppet installation, and he's both opinioned and motivated about where Puppet and related products should go. Please treat him nicely for the first week or so, and then begin bombarding him with requests. :) -- Always behave like a duck - keep calm and unruffled on the surface but paddle like the devil underneath. -- Jacob Braude - Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- 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] Accessing the puppet configuration settings from an external script?
Hi all, I'm working on a ext-node script that will use oauth to authenticate against the node database and I'm wondering if it is possible to read the puppet.conf file easily in this script so I can place the oauth key/secret into this file (and basically avoid maintaining my own config file!) Is there an easy way of doing this, or do I need to read in a parse the file myself? Thanks, Matt -- 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: ANNOUNCE: Puppet Dashboard 1.0.4 released!
Andreas, This error message indicates that the Puppet Dashboard won't start because your application version is older than your database schema. Specifically, your Puppet Dashboard code is expecting the schema shipped with v1.0.3 (schema 20100726070117), but your actual database schema is the one used by v1.0.4rc2 and v1.0.4 (schema 20100916183948). I strongly suspect that you have two different copies of the Puppet Dashboard installed: the v1.0.4 that you ran `rake db:migrate` against, and the v1.0.3 that Apache is configured to use. Please check the paths your webserver is using to ensure that they point to the expected version by checking the VERSION file in the Puppet Dashboard directory. At the very least, you should be able to go into the Puppet Dashboard directory, confirm that it's v1.0.4, and then run `./script/server -e production` to get it running again until you figure out what's going on with your webserver. -igal On Wed, Oct 20, 2010 at 4:42 AM, Andreas Paul a.p...@enbw.com wrote: I get the following error: Database isn't the current migration version: expected 20100726070117, got 20100916183948 You must either run 'rake db:migrate' or set environmental variable NO_MIGRATION_CHECK I upgraded from 1.0.4rc2 and did run 'rake RAILS_ENV=production db:migrate' before restarting apache. On Oct 20, 1:59 am, James Turnbull ja...@puppetlabs.com wrote: 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.mark... 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 -Uvhhttp://yum.puppetlabs.com/base/puppetlabs-repo-3.0-2.noarch.rpm;\ rpm -Uvhhttp://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.no... \ 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: debhttp://apt.puppetlabs.com/ubuntulucid main deb-srchttp://apt.puppetlabs.com/ubuntulucid 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
Re: [Puppet Users] puppetd 0.25.4 with puppetmaster 0.24.8?
Always upgrade the puppetmaster first. Clients will usually not work with a server that has an older major version. I've found that using the lucid (10.4) deb files in karmic (9.10) works fine if You get all the related ones. When ever you upgrade puppet, also upgrade facter. On Wed, Oct 20, 2010 at 11:32 AM, Ed Greenberg e...@greenberg.org wrote: Our puppetmaster runs 0.24.8 on Ubuntu 9.10. Our clients are either Ubuntu 9.10 or Ubuntu 8.04. We've just brought up our first Ubuntu 10.04 machine. This machine installs puppetd 0.25.4. The Ubuntu 10.04 machine can't seem to present it's certificate request properly. In my masterhttp.log, I see [2010-10-20 13:09:06] 174-143-141-55.static.cloud-ips.com - - [20/Oct/2010:13:09:05 CDT] PUT /production/certificate_request/ edglucid1.newhostingaccount.net HTTP/1.1 404 359 getting a 404. Also [2010-10-20 13:24:52] 174-143-141-55.static.cloud-ips.com - - [20/Oct/2010:13:24:52 CDT] GET /production/certificate/ca HTTP/1.1 404 322 There is no certificate pending to sign. My command line on the client side was /usr/sbin/puppetd --no-daemonize --verbose --onetime --server=xxx --fqdn= edglucid1.newhostingaccount.net Am I hitting a version incompatibility, and is there any hope for this other than installing a newer puppetmaster, from source (since Ubuntu 9.10 doesn't provide 0.25) or upgrading the puppetmaster server to Ubuntu 10.04? -- 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://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.
