Re: [Puppet Users] Re: Hostname fact doesn't handle hostnames with periods
http://projects.puppetlabs.com/issues/10001 I noticed we are also missing the ':timeout' option. ken. On Sun, Oct 9, 2011 at 11:06 PM, John Warburton wrote: > On 8 October 2011 09:26, Adrien Thebo wrote: >> >> You can effectively override a fact by setting the weight, as follows >> >> Facter.add(:hostname) do >> has_weight 200 >> setcode do >> # your own hostname implementation >> end >> end >> > > Now that is something worth knowing. Can this be added to the documentation? > I can't see reference to it in > http://docs.puppetlabs.com/guides/custom_facts.html or > http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts > > Thanks > > 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-users@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-users@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: Official puppetlabs position on cron vs puppet as a service?
On 08/10/11 21:22, Chris Phillips wrote: What better way to monitor the puppet runs than by executing that run as part of the check? I assume your Nagios plugin execution timeout must be insanely long? :) In the past I have considered using Nagios for things other than monitoring, and likewise using Puppet for things other than configuration. On both counts I decided it was probably best to set a boundary and not wilfully abuse these tools, since it's likely to go wrong sooner or later! In my organisation we use Nagios only to monitor, and Puppet only to configure. Have fun! Jonathan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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: Official puppetlabs position on cron vs puppet as a service?
On Mon, Oct 10, 2011 at 2:05 PM, Jonathan Gazeley
wrote:
> On 08/10/11 21:22, Chris Phillips wrote:
>>
>> What better way to monitor the puppet runs than by executing that run as
>> part of the check?
>
> I assume your Nagios plugin execution timeout must be insanely long? :)
>
> In the past I have considered using Nagios for things other than monitoring,
> and likewise using Puppet for things other than configuration. On both
> counts I decided it was probably best to set a boundary and not wilfully
> abuse these tools, since it's likely to go wrong sooner or later! In my
> organisation we use Nagios only to monitor, and Puppet only to configure.
>
> Have fun!
>
> Jonathan
If you are using foreman, its very easy to query the last puppet
report state, e.g.
curl -k -u $user:$pass https://foreman/hosts/`hostname
-f`/reports/last?format=json |prettify_json.rb
{
"report": {
"reported_at": "2011-10-10T13:03:02Z",
"metrics": {
"time": {
"group": 0.001799,
"class": 0.002389,
"config_retrieval": 2.4686119556427,
"cron": 0.00056,
"schedule": 0.002556,
"service": 0.702501,
"yumrepo": 0.081921,
"total": 4.6954209556427,
"mailalias": 0.000351,
"package": 0.012924,
"exec": 0.336481,
"file": 1.079741,
"filebucket": 0.000226,
"user": 0.00536
},
"events": {
"total": 0
},
"resources": {
"total": 212
},
"changes": {
"total": 0
}
},
"id": 269755,
"summary": "Success",
"host": "super.tlv.redhat.com",
"logs": [
],
"status": {
"failed": 0,
"restarted": 0,
"applied": 0,
"skipped": 0,
"failed_restarts": 0
}
}
}
Ohad
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@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-users@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: Official puppetlabs position on cron vs puppet as a service?
On 10 October 2011 13:05, Jonathan Gazeley wrote: > On 08/10/11 21:22, Chris Phillips wrote: > >> What better way to monitor the puppet runs than by executing that run as >> part of the check? >> > > I assume your Nagios plugin execution timeout must be insanely long? :) > > In the past I have considered using Nagios for things other than > monitoring, and likewise using Puppet for things other than configuration. > On both counts I decided it was probably best to set a boundary and not > wilfully abuse these tools, since it's likely to go wrong sooner or later! > In my organisation we use Nagios only to monitor, and Puppet only to > configure. > > always done within 30 seconds, and it's not like if it took longer on an occasional rollout it would impact puppet at all, temporarily messy as the monitor results might be. fundamentally though, with cron or puppetd being trivial simple, i'm more than happy to be doing it this way. Chris -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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: Package cannot be installed error.
Hi, in case you're still wondering, you're lacking the public key for the repository that serves the hudson package. Make sure to import the key using apt-key, then run apt-get update. For your security, you should make sure to use verified keys for all the repos you use. HTH, Felix On 09/30/2011 11:03 PM, Namrata wrote: > Also, during manual installation of hudson , this is necessary: > > Install these packages without verification [y/N]? > > I am not sure if it is not able to take "y" during installation. > Please help, thanks! > > On Sep 30, 10:41 am, Namrata wrote: >> I am trying to install hudson using puppet and I get the following >> error: >> >> err: /Stage[main]//Node[default]/Package[hudson]/ensure: change from >> absent to present failed: Execution of '/usr/bin/apt-get -q -y -o >> DPkg::Options::=--force-confold install hudson' returned 100: Reading >> package lists... >> Building dependency tree... >> Reading state information... >> The following NEW packages will be installed: >> hudson >> 0 upgraded, 1 newly installed, 0 to remove and 7 not upgraded. >> Need to get 0 B/56.2 MB of archives. >> After this operation, 57.6 MB of additional disk space will be used. >> WARNING: The following packages cannot be authenticated! >> hudson >> E: There are problems and -y was used without --force-yes >> >> I looked through the other similar errors in here but I do not have >> any missing keys. So, any clue on how to fix it? > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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: Official puppetlabs position on cron vs puppet as a service?
Most of my puppet runs take ~15 seconds or so, however my Nagios servers take up to 4 minutes to complete. On Mon, Oct 10, 2011 at 7:00 AM, Chris Phillips wrote: > > > On 10 October 2011 13:05, Jonathan Gazeley > wrote: > >> On 08/10/11 21:22, Chris Phillips wrote: >> >>> What better way to monitor the puppet runs than by executing that run as >>> part of the check? >>> >> >> I assume your Nagios execution timeout must be insanely long? :) >> >> In the past I have considered using Nagios for things other than >> monitoring, and likewise using Puppet for things other than configuration. >> On both counts I decided it was probably best to set a boundary and not >> wilfully abuse these tools, since it's likely to go wrong sooner or later! >> In my organisation we use Nagios only to monitor, and Puppet only to >> configure. >> >> > always done within 30 seconds, and it's not like if it took longer on an > occasional rollout it would impact puppet at all, temporarily messy as the > monitor results might be. > > fundamentally though, with cron or puppetd being trivial simple, i'm more > than happy to be doing it this way. > > > Chris > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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-users@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: Official puppetlabs position on cron vs puppet as a service?
that always seems to redirect me to 'login' (even though I am passing the -u
username:password)
Craig
On Oct 10, 2011, at 6:32 AM, Ohad Levy wrote:
> On Mon, Oct 10, 2011 at 2:05 PM, Jonathan Gazeley
> wrote:
>> On 08/10/11 21:22, Chris Phillips wrote:
>>>
>>> What better way to monitor the puppet runs than by executing that run as
>>> part of the check?
>>
>> I assume your Nagios plugin execution timeout must be insanely long? :)
>>
>> In the past I have considered using Nagios for things other than monitoring,
>> and likewise using Puppet for things other than configuration. On both
>> counts I decided it was probably best to set a boundary and not wilfully
>> abuse these tools, since it's likely to go wrong sooner or later! In my
>> organisation we use Nagios only to monitor, and Puppet only to configure.
>>
>> Have fun!
>>
>> Jonathan
>
> If you are using foreman, its very easy to query the last puppet
> report state, e.g.
>
> curl -k -u $user:$pass https://foreman/hosts/`hostname
> -f`/reports/last?format=json |prettify_json.rb
> {
> "report": {
>"reported_at": "2011-10-10T13:03:02Z",
>"metrics": {
> "time": {
>"group": 0.001799,
>"class": 0.002389,
>"config_retrieval": 2.4686119556427,
>"cron": 0.00056,
>"schedule": 0.002556,
>"service": 0.702501,
>"yumrepo": 0.081921,
>"total": 4.6954209556427,
>"mailalias": 0.000351,
>"package": 0.012924,
>"exec": 0.336481,
>"file": 1.079741,
>"filebucket": 0.000226,
>"user": 0.00536
> },
> "events": {
>"total": 0
> },
> "resources": {
>"total": 212
> },
> "changes": {
>"total": 0
> }
>},
>"id": 269755,
>"summary": "Success",
>"host": "super.tlv.redhat.com",
>"logs": [
>
>],
>"status": {
> "failed": 0,
> "restarted": 0,
> "applied": 0,
> "skipped": 0,
> "failed_restarts": 0
>}
> }
> }
>
>
> Ohad
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@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-users@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.
>
--
Craig White ~ craig.wh...@ttiltd.com
1.800.869.6908 ~~ www.ttiassessments.com
Need help communicating between generations at work to achieve your desired
success? Let us help!
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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] Can I merge Virtual Resources?
Hi! I've got a requirement that a few users need to have the same username,
but different passwords on qa & prod server. The users are currently
defined as
@users which gets realized in an appropriate module, and I've been thinking
about splitting out the users I need to have realized in different
environments and putting them in @qausers & @produsers, hoping that I could
say something like @users = @users + @{$env}users which would then contain
my "main" group of user definitions, plus my environment-specific ones.
Does anyone know of a good way of doing this? Am I going about this the
wrong way?
Thanks a lot!
Guy
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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: Facter 1.6.2. available
Facter 1.6.2 is a maintenance release containing fixes, updates and refactoring. Primary new features include updated facts for DragonFly BSD, Amazon Linux and Windows. A few other facts have been added and updated. Full release notes below. This release is available for download at: http://puppetlabs.com/downloads/facter/facter-1.6.2.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.6.2: http://projects.puppetlabs.com/projects/facter/ Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki RPMs available on yum.puppetlabs.com as well. # Facter 1.6.2 Release Notes ## Maint: (9555) Change all cases of tabs and 4 space indentation to 2 space indentation. Since 2 space indentation seems to be Puppets (and the ruby communities) standard this patch converts all incorrect indentation to 2 spaces. The fact that we were mixing the indentation was causing people to mix them within files - sometimes using 4 space, sometimes 2 space. This single change makes it consistent across all the code. ## New Fact: (9830) Add sshecdsakey fact From version 5.7 onward, openssh has support for elliptic curve DSA keys[1,2]. This commit adds a fact for those keytypes. 1 - http://openssh.org/txt/release-5.7 2 - http://tools.ietf.org/html/rfc5656 ## New Platform: (9404) Add memory & update processor facts for DragonFly and OpenBSD. Since there was no coverage for memory tests these have been added for the two OS's. Also since the mechanism for processor detection was changes this was fixed for OpenBSD. A similar mechanism was added for the new DragonFly BSD support. ## Fix (9404) De-clumsify CPU count detection and swap detection on OpenBSD. As part of the DragonFly BSD work is was noticed that the OpenBSD implementation could benefit from the same techniques so this commit aligns that. ## Fix (6728) Improve openvz/cloudlinux detection. Added more cloudlinux detection, which has /proc/lve/list present on cloudlinux hosts. Removed a default value from openvz_type detection, which could lead to a virtual value of "unknown" if the openvz check partially failed, which could cause other legitimate virtual tests to be skipped. ## New Platform: (7951) added OS support for Amazon Linux ## Maint: (9787) Change rspec format so we use the default, not document Current running rake spec in facter means we get the document output which is very verbose. Unfortunately we are forcing this in our .rspec file so you can’t override it on a user by user basis with ~/.rspec for example. I think we should not define —format, which means the default is progress (which is less verbose and better for the average Joe and hacker who just wants red light/green light) and then if people really want document format they can override this in their own ~/.rspec file. This way its the best of both worlds – more meaningful defaults and allowing user overrides. ##Fix (7726) Silence prtconf error message inside zones prtconf will output an error message when run inside a zone, which clutters up facter output. Redirected the stderr to /dev/null. ## Fix (4980, 6470) Fix architecture in Darwin and Ubuntu Architecture now relies on the hardwaremodel fact unless special cased otherwise, such as for linux distributions that require amd64 as the expected architecture. Ubuntu was added as a special case, OpenBSD was collapsed into the current architecture fact and Darwin was added by removing the kernel confine statement for the architecture fact. ##New fact: (6792) Added osfamily fact. Added osfamily fact to determine if a given operating system is a derivative of a common operating system. ##Fix (6515 and 2945) Fix processorcount for arm, sparc & ppc for linux. Previously we were unable to check processor type and count on other architectures for linux. This fix corrects that. To remove complication from the fact we have moved the logic for parsing cpuinfo and lsdev into their own static classes in Facter::Util::Processor. This is to help with stubbing and to segregate that action as now we have more conditional cases. Tests and corresponding cpuinfo fixtures have been added to test those alternative platforms as well. ##Fix (3856) Detect VirtualBox on Darwin as well as Linux and SunOS ## Fix (7996) Restrict solaris cpu processor detection x86_64 based solaris machines have a pkg_core_id field in output of kstat cpu_info, which denotes the core id of a specific core relative to the cpu. This could cause misreporting of processor count. The regex to count cores was restricted to prevent this. Addition
Re: [Puppet Users] Re: Official puppetlabs position on cron vs puppet as a service?
On Mon, Oct 10, 2011 at 5:16 PM, Craig White wrote:
> that always seems to redirect me to 'login' (even though I am passing the -u
> username:password)
>
I'm guessing you have ssl redirection turned on and you are using http
instead of https?
Ohad
> Craig
>
> On Oct 10, 2011, at 6:32 AM, Ohad Levy wrote:
>
>> On Mon, Oct 10, 2011 at 2:05 PM, Jonathan Gazeley
>> wrote:
>>> On 08/10/11 21:22, Chris Phillips wrote:
What better way to monitor the puppet runs than by executing that run as
part of the check?
>>>
>>> I assume your Nagios plugin execution timeout must be insanely long? :)
>>>
>>> In the past I have considered using Nagios for things other than monitoring,
>>> and likewise using Puppet for things other than configuration. On both
>>> counts I decided it was probably best to set a boundary and not wilfully
>>> abuse these tools, since it's likely to go wrong sooner or later! In my
>>> organisation we use Nagios only to monitor, and Puppet only to configure.
>>>
>>> Have fun!
>>>
>>> Jonathan
>>
>> If you are using foreman, its very easy to query the last puppet
>> report state, e.g.
>>
>> curl -k -u $user:$pass https://foreman/hosts/`hostname
>> -f`/reports/last?format=json |prettify_json.rb
>> {
>> "report": {
>> "reported_at": "2011-10-10T13:03:02Z",
>> "metrics": {
>> "time": {
>> "group": 0.001799,
>> "class": 0.002389,
>> "config_retrieval": 2.4686119556427,
>> "cron": 0.00056,
>> "schedule": 0.002556,
>> "service": 0.702501,
>> "yumrepo": 0.081921,
>> "total": 4.6954209556427,
>> "mailalias": 0.000351,
>> "package": 0.012924,
>> "exec": 0.336481,
>> "file": 1.079741,
>> "filebucket": 0.000226,
>> "user": 0.00536
>> },
>> "events": {
>> "total": 0
>> },
>> "resources": {
>> "total": 212
>> },
>> "changes": {
>> "total": 0
>> }
>> },
>> "id": 269755,
>> "summary": "Success",
>> "host": "super.tlv.redhat.com",
>> "logs": [
>>
>> ],
>> "status": {
>> "failed": 0,
>> "restarted": 0,
>> "applied": 0,
>> "skipped": 0,
>> "failed_restarts": 0
>> }
>> }
>> }
>>
>>
>> Ohad
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-users@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-users@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.
>>
>
> --
> Craig White ~ craig.wh...@ttiltd.com
> 1.800.869.6908 ~~ www.ttiassessments.com
>
> Need help communicating between generations at work to achieve your desired
> success? Let us help!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@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-users@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: More changes on yum.puppetlabs.com
On Thu, Oct 6, 2011 at 10:34 AM, Michael Stahnke wrote: > Greetings, > > I'd like to remove the cruft (no longer maintained) areas of > yum.puppetlabs.com. I fear they only cause confusion and offer > less-than-desirable experience for our users. > > I'd like to remove > > /base > /prosvc > /porsvc.unsigned > /SRMS > /sources > > I'd like to do this some time next week. This has been completed. Please let me know if you have issues. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.2.2 Available
This is a maintenance release of Puppet Dashboard 1.2.2. This release is available for download at: http://downloads.puppetlabs.com/dashboard/ We have included Debian and RPM packages as well as a tarball. RPMs are also available on yum.puppetlabs.com. See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.2.2 http://projects.puppetlabs.com/projects/dashboard Documentation is available at: http://docs.puppetlabs.com/dashboard/index.html # Highlights for this release ## (#9940) dashboard-workers can be managed as service The stop command in the puppet-dashboard-workers init script would fail when run using a puppet service resource. This had something to do with the way sudo works on EL. Removing the sudo from the stop function allows the service to be managed by puppet reliably. And because it is stopping the process, and not creating the process, it doesn't matter whether it runs as root or puppet-dashboard. ## (#9429) Prevent editing node name The uneditable node name was displayed in a text input control, which was less than ideal for a number of reasons. Now it's plain text. ## (#9429) makes node name field readonly during edit action The readonly attribute of the node name text field is set via the @readonly_name instance variable. When nil, the node name can be edited. This commit prevents the node name from being edited, though it can be set normally during node creation. ## (#9429) adds attr_readonly to name in the node model Changes to the name attribute of nodes are ignored, via the attr_readonly attribute in the model. In the view, readonly input controls are assigned a #EEE background. spec tests updated with readonly changes. ## (#9282) Change user in database.yml.example to "dashboard" Previously, our database.yml.example file suggested handing the keys to the root MySQL user to Dashboard, which is a poor security practice. This commit changes the default user suggestion to "dashboard", which is the default MySQL user used in Puppet Enterprise. ## (#9262) causes the contents of .section divs to scroll when overflowing This is a short-term solution to a larger problem. Dashboard is split into two columns, the sidebar (20% of window width), and the main content pane (80% of window width). The problem is when dealing with large strings of non-breaking text (e.g. file paths), the containing element runs off the screen unless accomodations are made (e.g. overflow: auto;). The better--long term--fix is to replace the 20%/80% column layout with one that allows the main content pane variable width. Thus, the entire window scrolls horizonally when elements overflow instead of requiring short-term fixes for each offending element. ## (#9215) Add a Rake task that removes nodes v1.2.2 === 484b323 Change node:delete to node:del for consistency 56b141c (#9215) Rename node:del to node:delete 20cf5fe (#9954) Add a rake task to add classes to a nodegroup d9eca18 (#9954) Add a rake task to list nodeclasses e75b51d (#9953) Add a rake task for listing nodegroups 14b93a2 Maint: adding VERSION_LINK to .gitignore 8725921 (#9940) dashboard-workers can be managed as service ce3868f (#9429) Prevent editing node name edbb48e (#9429) makes node name field readonly during edit action 14bc1e5 (#9429) adds attr_readonly to name in the node model a344e82 (#9366) removes conditional on .git for APP_VERSION_LINK 9ed1c19 (#9366) allows a custom version link to be specified 39a07de (#9773) Report content hidden 233fbf0 (#9756/Maint) Fix plugin loading. 54146c6 (#9756/Maint) Better guards around installed_plugins. 7b36bb3 (#9756) Autoload plugin initializers. 5311e6b (#9731) Refactor the Dashboard logo rendering. 1e4996c Maint: telling git to ignore MCollective logs 6c2e454 (#9306) tweaks base header styling to match markup changes c897d00 (#9571) tweaks header markup, method of importing CSS styles 5f381a0 (#9306) adds divs to header markup a63c1df (#9306) sanitizes header markup for assimilation by Riddler 22001cc (9571) exports global nav bar via /header.html ca7d7a5 (#9282) Rewrite explanatory text in database.yml.example 1f42a27 (#8825) allows configuration of logo dimensions and alt text 992af88 (#9262) causes the contents of .section divs to scroll when overflowing ad4641f (#9282) Change user in database.yml.example to "dashboard" 090538f (#9215) Add a Rake task that removes nodes -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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: Official puppetlabs position on cron vs puppet as a service?
On Oct 10, 2011, at 11:13 AM, Ohad Levy wrote:
> On Mon, Oct 10, 2011 at 5:16 PM, Craig White wrote:
>> that always seems to redirect me to 'login' (even though I am passing the -u
>> username:password)
>>
> I'm guessing you have ssl redirection turned on and you are using http
> instead of https?
strange... just tried again and it worked
and an fyi for anyone trying to use nginx/foreman, this seems to work fairly
well..
passenger_pre_start https://$SERVER:8142/;
server {
server_name $SERVER;
listen 8142;
root /var/www/foreman/public;
passenger_enabled on;
passenger_min_instances 1;
rails_env production;
rails_spawn_method smart;
passenger_user puppet;
passenger_use_global_queue off;
error_log logs/foreman_error.log error;
access_log logs/foreman_access.log combined;
ssl on;
ssl_certificate /etc/puppet/ssl/certs/$SERVER.pem;
ssl_certificate_key /etc/puppet/ssl/private_keys/$SERVER.pem;
ssl_crl /etc/puppet/ssl/ca/ca_crl.pem;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:!kEDH:+EXP:-SSLv2;
ssl_prefer_server_ciphers on;
ssl_verify_client off;
ssl_verify_depth 1;
ssl_session_cache builtin:1000 shared:SSL:10m;
}
Craig
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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] update vulnerable packages only if installed
Am I overlooking a native way to update vulnerable packages only if they are already installed? There's no option to set a package to 'latest' only if installed. OnlyIf and Unless don't operate on package resources. (Yum/CentOS but I imagine the issue is the same for all platforms) No, running a "yum upgrade all" is not plausible. Maintaining a list of packages which should be upgraded is plausible and expected. The obvious thing seems to be creatinga ruby fact that loads all packages into facts and then doing the logic based around that, but Luke and other have expressed concerns over doing this in the past. Is there a better way? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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] bug: --verbose on v2.6.6 doesn't always report changes. known and fixed in 2.7?
Nigel, just FYI I wanted to report that these issues are not the same. Yes, now that we have shifted to passenger it's clear that you have to run puppet twice to get the changes. But the original problem we saw was different: the changes did happen, but they weren't reported in the verbose output. The problem running under passenger is different -- it doesn't do the new thing until the next run. On Sep 26, 2011, at 4:39 PM, Nigel Kersten wrote: > On Mon, Sep 26, 2011 at 11:22 AM, Jo Rhett wrote: >> Nope, just puppet itself. (unless passenger is part of puppet and I could be >> running it without knowing it) > > We thought this problem was restricted to Passenger setups, but it > appears it was wider than that. > > http://projects.puppetlabs.com/issues/5318 > > We did push this for 2.6.9, so a great first step would be to try that > version and see if it resolves it for you. You can just put that > version on your master, there's no need to upgrade all your 2.6.6 > clients to check whether it fixes it. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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. > -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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] update vulnerable packages only if installed
AFAIK there's no native way. I would do this with a set of defines wrapped around the yum-security package (which allows you to list and operate on security updates only). On Mon, Oct 10, 2011 at 12:22 PM, Jo Rhett wrote: > Am I overlooking a native way to update vulnerable packages only if they > are already installed? There's no option to set a package to 'latest' only > if installed. OnlyIf and Unless don't operate on package resources. > (Yum/CentOS but I imagine the issue is the same for all platforms) > > No, running a "yum upgrade all" is not plausible. Maintaining a list of > packages which should be upgraded is plausible and expected. > > The obvious thing seems to be creatinga ruby fact that loads all packages > into facts and then doing the logic based around that, but Luke and other > have expressed concerns over doing this in the past. Is there a better way? > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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-users@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] can we move selinux attributes debugging into high level debug?
When I run "puppet agent --debug" I get about 1400 lines of selinux details, and about 120 lines of actual debug. These aren't actually changes to selinux attributes, just noting the selinux attribute of every file opened. I believe that this is unnecessary debug and makes it very difficult to track down other problems. Would Puppetlabs accept a feature request to move this selinux attribute echoing to higher or different debug level? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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] update vulnerable packages only if installed
yum-security doesn't work with CentOS. On Oct 10, 2011, at 1:18 PM, Aaron Grewell wrote: > AFAIK there's no native way. I would do this with a set of defines wrapped > around the yum-security package (which allows you to list and operate on > security updates only). > > On Mon, Oct 10, 2011 at 12:22 PM, Jo Rhett wrote: > Am I overlooking a native way to update vulnerable packages only if they are > already installed? There's no option to set a package to 'latest' only if > installed. OnlyIf and Unless don't operate on package resources. > (Yum/CentOS but I imagine the issue is the same for all platforms) > > No, running a "yum upgrade all" is not plausible. Maintaining a list of > packages which should be upgraded is plausible and expected. > > The obvious thing seems to be creatinga ruby fact that loads all packages > into facts and then doing the logic based around that, but Luke and other > have expressed concerns over doing this in the past. Is there a better way? > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and other > randomness > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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-users@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. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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] update vulnerable packages only if installed
How annoying. You could hack it up after installing yum-changelog with 'yum changelog 1 | grep CVE' I guess. Not pretty. On Mon, Oct 10, 2011 at 2:36 PM, Jo Rhett wrote: > yum-security doesn't work with CentOS. > > On Oct 10, 2011, at 1:18 PM, Aaron Grewell wrote: > > AFAIK there's no native way. I would do this with a set of defines wrapped > around the yum-security package (which allows you to list and operate on > security updates only). > > On Mon, Oct 10, 2011 at 12:22 PM, Jo Rhett wrote: > >> Am I overlooking a native way to update vulnerable packages only if they >> are already installed? There's no option to set a package to 'latest' only >> if installed. OnlyIf and Unless don't operate on package resources. >> (Yum/CentOS but I imagine the issue is the same for all platforms) >> >> No, running a "yum upgrade all" is not plausible. Maintaining a list of >> packages which should be upgraded is plausible and expected. >> >> The obvious thing seems to be creatinga ruby fact that loads all packages >> into facts and then doing the logic based around that, but Luke and other >> have expressed concerns over doing this in the past. Is there a better way? >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source and >> other randomness >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@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-users@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. > > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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-users@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] /etc/init.d/mysql =fail mysqld=success
Hello.
This is my mysql-server.pp file, both master and client are runing
ubuntu.
class mysql-server {
package { "mysql-server": ensure => installed }
package { "mysql-client": ensure => installed }
service { "mysql":
enable => true,
ensure => running,
require => Package["mysql-server"],
}
file { "/etc/mysql/my.cnf":
owner => "mysql", group => "mysql",
source => "puppet:///modules/mysql-server/my.cnf",
notify => Service["mysql"],
require => Package["mysql-server"],
}
exec { "set-mysql-password":
unless => "mysqladmin -uroot -psecret",
path => ["/bin", "/usr/bin"],
command => "mysqladmin -uroot password secret",
require => Service["mysql"],
}
exec { "set-nagios-password":
unless => "mysqladmin -unagiostest -psecret",
path => ["/bin", "/usr/bin"],
command => "mysqladmin -unagiostest password secret",
require => Service["mysql"],
}
}
---
When I run /etc/init.d/mysql start sql doesnt run
Code:
root@cloneubuntu:/var/log/mysql# date
Mon Oct 10 19:32:56 PDT 2011
root@cloneubuntu:/var/log/mysql# /etc/init.d/mysql start
Rather than invoking init scripts through /etc/init.d, use the
service(8)
utility, e.g. service mysql start
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start mysql
start: Job is already running: mysql
root@cloneubuntu:/var/log/mysql# cat /var/log/mysql/error.log
root@cloneubuntu:/var/log/mysql# ps ax | grep sql
4797 pts/0S+ 0:00 grep --color=auto sql
root@cloneubuntu:/var/log/mysql# cat /etc/mysql/my.cnf
[client]
port= 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice= 0
[mysqld]
user= mysql
socket = /var/run/mysqld/mysqld.sock
port= 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
skip-external-locking
bind-address= 0.0.0.0
key_buffer = 16M
max_allowed_packet = 16M
thread_stack= 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size= 16M
log_error= /var/log/mysql/error.log
expire_logs_days= 10
max_binlog_size = 100M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
root@cloneubuntu:/var/log/mysql#
However when i run mysqld alone, it works
Code:
root@cloneubuntu:/var/log/mysql# date
Mon Oct 10 19:34:21 PDT 2011
root@cloneubuntu:/var/log/mysql# mysqld &
[1] 4815
root@cloneubuntu:/var/log/mysql# cat /var/log/mysql/error.log
111010 19:34:30 [Note] Plugin 'FEDERATED' is disabled.
111010 19:34:30 InnoDB: Started; log sequence number 0 44233
111010 19:34:30 [Note] Event Scheduler: Loaded 0 events
111010 19:34:30 [Note] mysqld: ready for connections.
Version: '5.1.41-3ubuntu12.10' socket: '/var/run/mysqld/mysqld.sock'
port: 3306 (Ubuntu)
root@cloneubuntu:/var/log/mysql# ps ax | grep sql
4815 pts/0Sl 0:00 mysqld
4830 pts/0S+ 0:00 grep --color=auto sql
root@cloneubuntu:/var/log/mysql# mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.41-3ubuntu12.10 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql>
I cannot reinstall mysql, I have a feeling it's an issue with the
init.d script or somethign along those lines.
Please help :S
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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] /etc/init.d/mysql =fail mysqld=success
1) not a puppet problem
2) run initdb
On Oct 10, 2011 7:47 PM, "John Bower" wrote:
> Hello.
>
> This is my mysql-server.pp file, both master and client are runing
> ubuntu.
>
>
>
>
> class mysql-server {
>
> package { "mysql-server": ensure => installed }
> package { "mysql-client": ensure => installed }
> service { "mysql":
>enable => true,
>ensure => running,
>require => Package["mysql-server"],
> }
>
> file { "/etc/mysql/my.cnf":
>owner => "mysql", group => "mysql",
>source => "puppet:///modules/mysql-server/my.cnf",
>notify => Service["mysql"],
>require => Package["mysql-server"],
> }
>
>
> exec { "set-mysql-password":
>unless => "mysqladmin -uroot -psecret",
>path => ["/bin", "/usr/bin"],
>command => "mysqladmin -uroot password secret",
>require => Service["mysql"],
> }
>
>
> exec { "set-nagios-password":
>unless => "mysqladmin -unagiostest -psecret",
>path => ["/bin", "/usr/bin"],
>command => "mysqladmin -unagiostest password secret",
>require => Service["mysql"],
> }
>
>
> }
> ---
>
>
>
>
> When I run /etc/init.d/mysql start sql doesnt run
>
> Code:
>
> root@cloneubuntu:/var/log/mysql# date
> Mon Oct 10 19:32:56 PDT 2011
> root@cloneubuntu:/var/log/mysql# /etc/init.d/mysql start
> Rather than invoking init scripts through /etc/init.d, use the
> service(8)
> utility, e.g. service mysql start
>
> Since the script you are attempting to invoke has been converted to an
> Upstart job, you may also use the start(8) utility, e.g. start mysql
> start: Job is already running: mysql
> root@cloneubuntu:/var/log/mysql# cat /var/log/mysql/error.log
>
> root@cloneubuntu:/var/log/mysql# ps ax | grep sql
> 4797 pts/0S+ 0:00 grep --color=auto sql
> root@cloneubuntu:/var/log/mysql# cat /etc/mysql/my.cnf
> [client]
> port= 3306
> socket = /var/run/mysqld/mysqld.sock
>
>
> [mysqld_safe]
> socket = /var/run/mysqld/mysqld.sock
> nice= 0
>
> [mysqld]
>
>
> user= mysql
> socket = /var/run/mysqld/mysqld.sock
> port= 3306
> basedir = /usr
> datadir = /var/lib/mysql
> tmpdir = /tmp
> skip-external-locking
> bind-address= 0.0.0.0
> key_buffer = 16M
> max_allowed_packet = 16M
> thread_stack= 192K
> thread_cache_size = 8
> myisam-recover = BACKUP
> query_cache_limit = 1M
> query_cache_size= 16M
>
> log_error= /var/log/mysql/error.log
>
> expire_logs_days= 10
> max_binlog_size = 100M
>
>
>
> [mysqldump]
> quick
> quote-names
> max_allowed_packet = 16M
>
> [mysql]
>
> [isamchk]
> key_buffer = 16M
>
> !includedir /etc/mysql/conf.d/
>
> root@cloneubuntu:/var/log/mysql#
>
> However when i run mysqld alone, it works
>
> Code:
>
> root@cloneubuntu:/var/log/mysql# date
> Mon Oct 10 19:34:21 PDT 2011
> root@cloneubuntu:/var/log/mysql# mysqld &
> [1] 4815
> root@cloneubuntu:/var/log/mysql# cat /var/log/mysql/error.log
>
> 111010 19:34:30 [Note] Plugin 'FEDERATED' is disabled.
> 111010 19:34:30 InnoDB: Started; log sequence number 0 44233
> 111010 19:34:30 [Note] Event Scheduler: Loaded 0 events
> 111010 19:34:30 [Note] mysqld: ready for connections.
> Version: '5.1.41-3ubuntu12.10' socket: '/var/run/mysqld/mysqld.sock'
> port: 3306 (Ubuntu)
> root@cloneubuntu:/var/log/mysql# ps ax | grep sql
> 4815 pts/0Sl 0:00 mysqld
> 4830 pts/0S+ 0:00 grep --color=auto sql
> root@cloneubuntu:/var/log/mysql# mysql -u root
> Welcome to the MySQL monitor. Commands end with ; or \g.
> Your MySQL connection id is 1
> Server version: 5.1.41-3ubuntu12.10 (Ubuntu)
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input
> statement.
>
> mysql>
>
> I cannot reinstall mysql, I have a feeling it's an issue with the
> init.d script or somethign along those lines.
>
> Please help :S
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@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-users@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: Official puppetlabs position on cron vs puppet as a service?
Most things are ok if you only have 10 servers On Oct 8, 2011 1:22 PM, "Chris Phillips" wrote: > My take on it is to run it from our nagios server. What better way to > monitor the puppet runs than by executing that run as part of the check? > retry intervals also help push changes out much quicker if they could take > multiple runs etc. > > We also run a single daily cron job. > > Chris > > On 8 October 2011 19:32, Matthew Nicholson > wrote: > >> We combine these. We run as a service, but have a daily cron, with random >> time spread among our hosts, to stop/start the service and clean up stale >> .pid files. This is more of a hold over from our early days more than >> anything, but it works, doesn't cause issues, and keeps the runs spread >> out. >> >> >> >> On Fri, Oct 7, 2011 at 9:27 PM, Larry Ludwig wrote: >> >>> Mostly stlll run as cron. Though for some instances we run as a daemon. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/puppet-users/-/itTFPtfZLocJ. >>> >>> To post to this group, send email to puppet-users@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. >>> >> >> >> >> -- >> Matthew Nicholson >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@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-users@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-users@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.
