Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

[Matt Robinson]

On Tue, Aug 30, 2011 at 8:15 AM, David Thompson
 wrote:
>
>> basically anyone attempting to do anything reasonable with ruby on RHEL 5.x 
>> (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 
>> version is just short of useless and has implemented other fixes.
>
> Some comments on this thread, and current software development trends
> in general.
>
> Craig, the version of ruby that ships with RHEL 5 was good enough for
> many things, including dashboard <= 1.1.  So, while it may have
> problems and limitations,  I think you overstate things to say it is
> "just short of useless."
>
> Also, "long in the tooth" is subjective; RHEL 5 (and the derivative
> works) are currently supported distributions with significant
> installed user bases.  Many environments, for many different reasons,
> have decided that EL is the best choice for them.  It's important to
> respect those decisions.  As a system administrator, I see people
> ignore compatibility with the EL distros regularly, and it's
> unfortunate that many people wave their hands with phrases like 'long
> in the tooth,' 'next to useless,' or 'any modern linux
> distribution' (from another project I was asked to install recently),
> which don't mesh well with the realities of significant parts of the
> installed linux base.
>
> In this case, as was pointed out, there are fairly simple ways to get
> ruby >1.8.5 onto an EL 5 system.  But when someone writes an app
> against the lastest and greatest libgtk and friends, and uses the most
> recent versions of everything because that's what's available on their
> latest ubuntu release, it simply cuts them off from many potential
> users, for perhaps very little developer gain.  Developers should
> consider carefully the run-time requirements vs. the target audience
> as part of the development process.
>
> I agree with Ramin that a different numbering scheme for ruby versions
> would have made more sense.  A tiny version change (e.g. 1.8.5 to
> 1.8.7) would be understood in many release contexts to contain bug-
> fixes only and introduce no higher-level incompatibilities (a very
> broad simplification, but still true).  Version numbers mean something
> very different to the ruby development team than they do to many other
> knowledgeable people.
>
> All that being said, if the dashboard development folks have decided
> that 1.8.7 is needed, then 1.8.7 it is.  Perhaps pointers to suitable
> ruby builds could be included in the release notes (or on the download
> page, etc., etc.) as an aid to those who will need to upgrade.

It's not just Dashboard that decided not to support older versions of
Ruby, Rails (the framework Dashboard uses) doesn't support older
version of Ruby.

http://rubyonrails.org/download
We recommend Ruby 1.8.7 or Ruby 1.9.2 for use with Rails. Ruby
1.8.6 and earlier are not supported, neither is version 1.9.1.

While it's true this statement applies explicitly to Rails 3.x rather
than Rails 2.3.x (which Dashboard is still based on), there is nowhere
we could find that explicitly says that Rails 2.3.x *supports* Ruby
1.8.5, so there's no guarantee that security fixes (of which there
were a few applied recently) will support Ruby 1.8.5.

It's probably a good idea to briefly mention a few ways (numerous were
mentioned in this thread) to get newer Rubies in the Dashboard manual
(http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html#installing-dependencies).
 I've included our excellent documentation writer on this thread.

-- 
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] Need some advice: Clients that change name and IP address

[Scott Smith]

http://docs.puppetlabs.com/references/stable/configuration.html#certname

On Tue, Aug 30, 2011 at 8:32 PM, Dan White  wrote:

>
> On Aug 30, 2011, at 9:45 PM, Gary Larizza wrote:
>
>
>
> On Tue, Aug 30, 2011 at 8:43 PM, Dan White  wrote:
>
>>
>> On Aug 30, 2011, at 9:17 PM, Nigel Kersten wrote:
>>
>>
>>
>> On Tue, Aug 30, 2011 at 9:28 AM, Dan White  wrote:
>>
>>> The environment I work in has dev, QA, and production divisions.
>>> New machines are built/loaded in dev and then moved, if necessary to QA
>>> or production after they have been configured and verified.  In moving, the
>>> machine in question will change its IP address and hostname.
>>>
>>> I have set up a Cobbler server to shortcut this, and I am now tasked with
>>> adding Puppet to the mixture.
>>>
>>> Can anyone suggest a maintainable way for Puppet to handle machines that
>>> get moved and renamed as described ?
>>>
>>> My first thought is to remove all the files generated by making the
>>> machine a puppet client and then just re-add it as a new client in the new
>>> location with the new name, but that feels like a brute-force solution.
>>>
>>
>> Don't use hostnames for your certnames?
>>
>> I've used UUIDs for this sort of deployment in the past.
>>
>>
>> Details, please.
>>
>
> The certname setting can be changed in the agent section of puppet.conf.
>  When I managed Puppet down to the desktop, I would typically set the
> client's certname to their serial number (which wouldn't change unless the
> Motherboard was changed).  Because of this, they could change their Hostname
> to their heart's content and the SSL certs for Puppet wouldn't be affected.
>
>
> Would an example be possible ?  I think I understand what you are saying,
> but as a N00b PuppetMaster, I cannot quite figure out how to make it happen.
>
>  --
> 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] Need some advice: Clients that change name and IP address

[Dan White]

On Aug 30, 2011, at 9:45 PM, Gary Larizza wrote:




On Tue, Aug 30, 2011 at 8:43 PM, Dan White  wrote:

On Aug 30, 2011, at 9:17 PM, Nigel Kersten wrote:




On Tue, Aug 30, 2011 at 9:28 AM, Dan White  wrote:
The environment I work in has dev, QA, and production divisions.
New machines are built/loaded in dev and then moved, if necessary  
to QA or production after they have been configured and verified.   
In moving, the machine in question will change its IP address and  
hostname.


I have set up a Cobbler server to shortcut this, and I am now  
tasked with adding Puppet to the mixture.


Can anyone suggest a maintainable way for Puppet to handle machines  
that get moved and renamed as described ?


My first thought is to remove all the files generated by making the  
machine a puppet client and then just re-add it as a new client in  
the new location with the new name, but that feels like a brute- 
force solution.


Don't use hostnames for your certnames?

I've used UUIDs for this sort of deployment in the past.



Details, please.

The certname setting can be changed in the agent section of  
puppet.conf.  When I managed Puppet down to the desktop, I would  
typically set the client's certname to their serial number (which  
wouldn't change unless the Motherboard was changed).  Because of  
this, they could change their Hostname to their heart's content and  
the SSL certs for Puppet wouldn't be affected.


Would an example be possible ?  I think I understand what you are  
saying, but as a N00b PuppetMaster, I cannot quite figure out how to  
make it happen.


--
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] Need some advice: Clients that change name and IP address

[Gary Larizza]

On Tue, Aug 30, 2011 at 8:43 PM, Dan White  wrote:

>
> On Aug 30, 2011, at 9:17 PM, Nigel Kersten wrote:
>
>
>
> On Tue, Aug 30, 2011 at 9:28 AM, Dan White  wrote:
>
>> The environment I work in has dev, QA, and production divisions.
>> New machines are built/loaded in dev and then moved, if necessary to QA or
>> production after they have been configured and verified.  In moving, the
>> machine in question will change its IP address and hostname.
>>
>> I have set up a Cobbler server to shortcut this, and I am now tasked with
>> adding Puppet to the mixture.
>>
>> Can anyone suggest a maintainable way for Puppet to handle machines that
>> get moved and renamed as described ?
>>
>> My first thought is to remove all the files generated by making the
>> machine a puppet client and then just re-add it as a new client in the new
>> location with the new name, but that feels like a brute-force solution.
>>
>
> Don't use hostnames for your certnames?
>
> I've used UUIDs for this sort of deployment in the past.
>
>
> Details, please.
>

The certname setting can be changed in the agent section of puppet.conf.
 When I managed Puppet down to the desktop, I would typically set the
client's certname to their serial number (which wouldn't change unless the
Motherboard was changed).  Because of this, they could change their Hostname
to their heart's content and the SSL certs for Puppet wouldn't be affected.

>  --
> 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.
>



-- 

Gary Larizza
Professional Services Engineer
Puppet Labs

Join us for PuppetConf , September 22nd and
23rd in Portland, OR!

-- 
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] Need some advice: Clients that change name and IP address

[Dan White]

On Aug 30, 2011, at 9:17 PM, Nigel Kersten wrote:




On Tue, Aug 30, 2011 at 9:28 AM, Dan White  wrote:
The environment I work in has dev, QA, and production divisions.
New machines are built/loaded in dev and then moved, if necessary to  
QA or production after they have been configured and verified.  In  
moving, the machine in question will change its IP address and  
hostname.


I have set up a Cobbler server to shortcut this, and I am now tasked  
with adding Puppet to the mixture.


Can anyone suggest a maintainable way for Puppet to handle machines  
that get moved and renamed as described ?


My first thought is to remove all the files generated by making the  
machine a puppet client and then just re-add it as a new client in  
the new location with the new name, but that feels like a brute- 
force solution.


Don't use hostnames for your certnames?

I've used UUIDs for this sort of deployment in the past.



Details, please.

--
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] Need some advice: Clients that change name and IP address

[Nigel Kersten]

On Tue, Aug 30, 2011 at 9:28 AM, Dan White  wrote:

> The environment I work in has dev, QA, and production divisions.
> New machines are built/loaded in dev and then moved, if necessary to QA or
> production after they have been configured and verified.  In moving, the
> machine in question will change its IP address and hostname.
>
> I have set up a Cobbler server to shortcut this, and I am now tasked with
> adding Puppet to the mixture.
>
> Can anyone suggest a maintainable way for Puppet to handle machines that
> get moved and renamed as described ?
>
> My first thought is to remove all the files generated by making the machine
> a puppet client and then just re-add it as a new client in the new location
> with the new name, but that feels like a brute-force solution.
>

Don't use hostnames for your certnames?

I've used UUIDs for this sort of deployment in the past.




>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> 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.
>
>


-- 
Nigel Kersten
Product Manager, Puppet Labs

*Join us for **PuppetConf *

Sept 22/23 Portland, Oregon, USA.
*
*

-- 
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] sudoers type

[windowsrefund]

Would anyone here like to be able to manage their sudoers bits with a
native type rather than using static files or ERB templates? I have
the beginnings of something over at 
https://github.com/windowsrefund/puppet-sudoers
and would really appreciate involvement from the community. It does
not do anything fancy like manage aliases or other exotic aspects of a
sudoers file. That said, it meets my immediate needs by managing user/
group entries along with an optional NOPASSWD and associated commands.

All the best,
Adam

-- 
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: Having trouble with create_resources

[Nan Liu]

On Tue, Aug 30, 2011 at 12:17 PM, Scott Rankin  wrote:
> I just figured that out.  If I change it to a defined resource, it works.
>  What led me in the wrong direction, though, was this sentence in the
> function documentation:
> " This is currently tested for defined resources, classes, as well as native
> types"
>
> I guess that's not really the case?

I need to be more precise about what I write, it will work for a class:

class hello_world {
  notify { "hi": }
}

create_resource("class", {hello_world})

I should of wrote "in your case, create_resource is intended for
resources, not classes."

Thanks,

Nan

-- 
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] Composing a text file with Puppet

[Daniel Maher]

On 08/30/2011 04:15 PM, M C wrote:

Hi,

is it possible to push a file (with "source" or "content") and then add
lines without having Puppet to regenerate it every time it runs?
And, how can I add, remove or alter text lines without keeping old
contents? Note: i want resources to be executed only if something
actually changes.

Please help, thanks.


Hello,

I'm not entirely sure if I understand your use-case properly; however, 
for all instances of text-file manipulation, I have found the "concat" 
module to be _extremely_ useful.


https://github.com/ripienaar/puppet-concat


--
Daniel Maher
« makin' plans now to live on Mars 'cuz I got Earth on lock. »

--
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] Some beginner's questions...

[Daniel Pittman]

On Tue, Aug 30, 2011 at 00:43, Francis GALIEGUE  wrote:
> On Mon, Aug 29, 2011 at 19:36, Daniel Pittman  wrote:
>> On Mon, Aug 29, 2011 at 00:51, Martin Alfke  wrote:
>>> On 08/29/2011 09:10 AM, Francis GALIEGUE wrote:

 First, we want to use push from the server, not pull from the clients:
 is that feasible?
>>>
>>> Yes, that is possible.
>>> The client has to run in listen mode.
>>> On the master you use puppet kick 
>>> http://docs.puppetlabs.com/man/kick.html
>>
>> That really only triggers the client to poll the server.  Out of the
>> box, it isn't possible to use a server push mode, though you can fake
>> it by triggering poll on demand using any number of tools.
>> (MCollective, for example, is pretty awesome at doing this, and I used
>> that quite frequently at my previous job.)
>>
>> Why do you want to do this?  Perhaps there is a better way to achieve
>> the outcome you are after?
>
> Well, we have an Apache/Tomcat setup which serves 50+ sites total, a
> part of which is production and the other testing. Right now we have
> tools on Apache which handles upgrades for one particular site. What
> we want to do is having puppet manage all this instead.

Ah, and you want to run Puppet on the machines at the same time, to
control when they get upgraded, right?

If so, you don't really care if Puppet pulls configuration from the
master, you just want to run it at the right time.

Anything can do it, but either `puppet kick`, mcollective, or just ssh
in a "for loop" would be fine.

Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
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: howto make file resource purge option aware of other puppet resources managed files

[Daniel Pittman]

Oh, dear.  Yes, John has it. :/

This is definitely a bug, and something we should fix.  Can you file a
ticket with the details, so that we don't lose track of this?

Daniel

On Tue, Aug 30, 2011 at 06:26, jcbollinger  wrote:
> You put your finger on it when you wrote "It will purge files managed
> by other puppet resources in the same directory," but Daniel missed
> your meaning, as did I on my first reading.
>
> You have tripped over a subtlety in the meaning of File's 'purge'
> parameter: it removes files that are not managed *via File
> resources*.  It is not aware of files that are managed via other
> resources.  You might consider filing a ticket about this, but do
> check first whether there's an existing one (i.e. I didn't).
>
> On the other hand, one reason you've run into trouble is that you're
> mixing levels of resource abstraction and effectively managing the
> same physical resources through two independent paths.  To ensure that
> only the repos managed via Puppet are in fact present at all, you
> should be using the Resources metaresource:
>
> resources { 'yumrepo': purge => true }
>
> That says more directly what you seem really to want to say, without
> assuming any particular back-end storage for repository declarations.
> Moreover, it should do the right thing if you happen to end up with
> managed and unmanaged repositories declared in the same file.  (Note:
> do not set the 'purge' parameter for File['/etc/yum.repos.d'], or set
> it to 'false'.)
>
>
> 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.
>
>



-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
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] Need some advice: Clients that change name and IP address

[Dan White]

The environment I work in has dev, QA, and production divisions.
New machines are built/loaded in dev and then moved, if necessary to QA or 
production after they have been configured and verified.  In moving, the 
machine in question will change its IP address and hostname.

I have set up a Cobbler server to shortcut this, and I am now tasked with 
adding Puppet to the mixture.

Can anyone suggest a maintainable way for Puppet to handle machines that get 
moved and renamed as described ?

My first thought is to remove all the files generated by making the machine a 
puppet client and then just re-add it as a new client in the new location with 
the new name, but that feels like a brute-force solution.

“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

-- 
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: Having trouble with create_resources

[Scott Rankin]

I just figured that out.  If I change it to a defined resource, it works. 
 What led me in the wrong direction, though, was this sentence in the 
function documentation:  

" This is currently tested for defined resources, classes, as well as native 
types"

I guess that's not really the case?  

On Tuesday, August 30, 2011 12:08:58 PM UTC-4, Nan Liu wrote:
>
> create_resource is for resources, not classes. Also if you change it
> from a class to a define, the resource name in your example would be:
> production_scp_acounts:scp_accounts. If you want a custom resource
> called scp::account, your module layout should be:
>
> modules
>   - scp
> - manifests
>- account.pp
>
> define scp::account {
> ...
> }
>
> Thanks,
>
> Nan
>
>

-- 
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/-/Y2Mqs6v58IMJ.
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: Having trouble with create_resources

[Nan Liu]

On Tue, Aug 30, 2011 at 11:55 AM, Scott Rankin  wrote:
> Update - the above error was happening because I had left in an "include
> 'scp_account'" statement at the top.  I took that out, but now I'm running
> into this issue:
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> could not create resource of unknown type
> production_scp_accounts::scp_account
>
> My directory structure looks like this:
> modules
>     production_scp_accounts
>         init.pp
>         scp_account.pp
> The create_resources call is in init.pp, in a class called
> "production_scp_accounts".  scp_account.pp has a class called
> "production_scp_accounts::scp_account", which I thought would be
> automatically picked up because I'm following the namespacing rules.
> Any thoughts?

create_resource is for resources, not classes. Also if you change it
from a class to a define, the resource name in your example would be:
production_scp_acounts:scp_accounts. If you want a custom resource
called scp::account, your module layout should be:

modules
  - scp
- manifests
   - account.pp

define scp::account {
...
}

Thanks,

Nan

-- 
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: Announce: Dashboard 1.2.0 is available now

[Christopher McCrory]

+1 for all of it.


On Tue, 2011-08-30 at 08:15 -0700, David Thompson wrote:
> > basically anyone attempting to do anything reasonable with ruby on RHEL 5.x 
> > (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 
> > version is just short of useless and has implemented other fixes.
> 
> Some comments on this thread, and current software development trends
> in general.
> 
> Craig, the version of ruby that ships with RHEL 5 was good enough for
> many things, including dashboard <= 1.1.  So, while it may have
> problems and limitations,  I think you overstate things to say it is
> "just short of useless."
> 
> Also, "long in the tooth" is subjective; RHEL 5 (and the derivative
> works) are currently supported distributions with significant
> installed user bases.  Many environments, for many different reasons,
> have decided that EL is the best choice for them.  It's important to
> respect those decisions.  As a system administrator, I see people
> ignore compatibility with the EL distros regularly, and it's
> unfortunate that many people wave their hands with phrases like 'long
> in the tooth,' 'next to useless,' or 'any modern linux
> distribution' (from another project I was asked to install recently),
> which don't mesh well with the realities of significant parts of the
> installed linux base.
> 
> In this case, as was pointed out, there are fairly simple ways to get
> ruby >1.8.5 onto an EL 5 system.  But when someone writes an app
> against the lastest and greatest libgtk and friends, and uses the most
> recent versions of everything because that's what's available on their
> latest ubuntu release, it simply cuts them off from many potential
> users, for perhaps very little developer gain.  Developers should
> consider carefully the run-time requirements vs. the target audience
> as part of the development process.
> 
> I agree with Ramin that a different numbering scheme for ruby versions
> would have made more sense.  A tiny version change (e.g. 1.8.5 to
> 1.8.7) would be understood in many release contexts to contain bug-
> fixes only and introduce no higher-level incompatibilities (a very
> broad simplification, but still true).  Version numbers mean something
> very different to the ruby development team than they do to many other
> knowledgeable people.
> 
> All that being said, if the dashboard development folks have decided
> that 1.8.7 is needed, then 1.8.7 it is.  Perhaps pointers to suitable
> ruby builds could be included in the release notes (or on the download
> page, etc., etc.) as an aid to those who will need to upgrade.
> 


-- 
Christopher McCrory
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

-- 
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: Having trouble with create_resources

[Scott Rankin]

Update - the above error was happening because I had left in an "include 
'scp_account'" statement at the top.  I took that out, but now I'm running 
into this issue:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
could not create resource of unknown type 
production_scp_accounts::scp_account 

My directory structure looks like this:

modules
production_scp_accounts
init.pp
scp_account.pp

The create_resources call is in init.pp, in a class called 
"production_scp_accounts".  scp_account.pp has a class called 
"production_scp_accounts::scp_account", which I thought would be 
automatically picked up because I'm following the namespacing rules.  

Any thoughts? 

-- 
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/-/_tWn21wMHTgJ.
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: howto make file resource purge option aware of other puppet resources managed files

[Nan Liu]

On Tue, Aug 30, 2011 at 11:07 AM, piavlo  wrote:
> Hi Nan
>
> Adding
> file { "/etc/yum.repos.d/${name}.repo":
>  ensure => file
> }
> took care of the problem.
>
> I still wonder if it should have worked without explicit file
> resource?
> Or "purge" is not supposed to be aware of other non file puppet
> resources?

The purge attribute for file is only aware of file resources and not
other puppet resources that creates a file. I suppose a feature
request to patch yumrepo type to autocreate a file will resolve this
issue, not sure if that has any undesirable side effects and that's a
decision for Puppet's product manager.

Thanks,

Nan

-- 
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: Announce: Dashboard 1.2.0 is available now

[David Thompson]

> basically anyone attempting to do anything reasonable with ruby on RHEL 5.x 
> (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 
> version is just short of useless and has implemented other fixes.

Some comments on this thread, and current software development trends
in general.

Craig, the version of ruby that ships with RHEL 5 was good enough for
many things, including dashboard <= 1.1.  So, while it may have
problems and limitations,  I think you overstate things to say it is
"just short of useless."

Also, "long in the tooth" is subjective; RHEL 5 (and the derivative
works) are currently supported distributions with significant
installed user bases.  Many environments, for many different reasons,
have decided that EL is the best choice for them.  It's important to
respect those decisions.  As a system administrator, I see people
ignore compatibility with the EL distros regularly, and it's
unfortunate that many people wave their hands with phrases like 'long
in the tooth,' 'next to useless,' or 'any modern linux
distribution' (from another project I was asked to install recently),
which don't mesh well with the realities of significant parts of the
installed linux base.

In this case, as was pointed out, there are fairly simple ways to get
ruby >1.8.5 onto an EL 5 system.  But when someone writes an app
against the lastest and greatest libgtk and friends, and uses the most
recent versions of everything because that's what's available on their
latest ubuntu release, it simply cuts them off from many potential
users, for perhaps very little developer gain.  Developers should
consider carefully the run-time requirements vs. the target audience
as part of the development process.

I agree with Ramin that a different numbering scheme for ruby versions
would have made more sense.  A tiny version change (e.g. 1.8.5 to
1.8.7) would be understood in many release contexts to contain bug-
fixes only and introduce no higher-level incompatibilities (a very
broad simplification, but still true).  Version numbers mean something
very different to the ruby development team than they do to many other
knowledgeable people.

All that being said, if the dashboard development folks have decided
that 1.8.7 is needed, then 1.8.7 it is.  Perhaps pointers to suitable
ruby builds could be included in the release notes (or on the download
page, etc., etc.) as an aid to those who will need to upgrade.

-- 
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] Deploying PHP 5.3 on CentOS 5.6 with Puppet

[Tim Yim]

Upgrading PHP on several hundred servers can be a nightmare!
Especially since this is my first task as the latest 'sucker' who made
the change from senior developer to sys admin. Luckily for me, my
predecessors were well versed in this type of problem and took on the
herculean task of setting up and deploying Puppet on every single
node! AND... they already set up our Puppet master nodes including a
vast and comprehensive library of custom Puppet modules enabling us to
piece together any type of server configuration we need.

So let me get this straight: Puppet is already available, and there is
an already existing PHP Puppet module? Let's drop in the new PHP RPM
and go for it! Right?

Not exactly. Turns out we need to come up with a new format for
writing Puppet modules that provides even more flexibility than our
existing format offers. This is that journey.

https://sites.google.com/site/timyimblog/blog/deploying-php53-on-centos-with-puppet

-- 
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] Having trouble with create_resources

[Scott Rankin]

Hey all,

I'm running puppet 2.7.3 on CentOS, and am trying to use the new 
create_resources function.  I have a class that looks like this:

scp_account($userid, $unixid, $password) {
.
}

and I'm trying to call it with a hash of parameters like so:

# Create a hash of the scp accounts
$scp_accounts = {
'joe' => {userid => 'joe', unixid => '700', password => 
'$1$sdfasdfasdfasdfsdaf'},
'bob' => {userid => 'bob', unixid => '701', password => 
'$1$asdfsdfsadfasdfsadf'}
}
create_resources('scp_account', $scp_accounts) 

However - when I try to run it, I'm getting an error like so:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Must pass userid to Class[Production_scp_accounts::Scp_account] at 
/etc/puppet/modules/production_scp_accounts/manifests/scp_account.pp:1

I'm sure it's user error, but I'm having a hard time figuring out exactly 
what I'm doing wrong. 

Thanks! 

-- 
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/-/PiHuiZtUZQQJ.
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: howto make file resource purge option aware of other puppet resources managed files

[piavlo]

Hi Nan

Adding
file { "/etc/yum.repos.d/${name}.repo":
  ensure => file
}
took care of the problem.

I still wonder if it should have worked without explicit file
resource?
Or "purge" is not supposed to be aware of other non file puppet
resources?

Thanks
Alex

On Aug 30, 5:11 pm, Nan Liu  wrote:
> On Mon, Aug 29, 2011 at 7:38 PM, piavlo  wrote:
> > Hi Daniel,
>
> > it looks indeed that it works in some/most cases - I tried to create a
> > minimal test class to check it using only file resources and it works
> > as you say - and as I want. So I have to post here one of the actual
> > not so minimal use case which depend on the expected behaviour.
>
> > -
> > #Class to setup specific yum repos
> > class ssa::yum {
>
> >  class { '::yum': }
>
> >  class { 'yum::epel': enable => true }
> >  class { 'yum::rpmforge': enable => true }
> >  class { 'yum::nixval': enable => true }
> >  class { 'yum::cloudera': enable => true }
>
> >  class { 'yum::zabbix': enable => false }
> >  class { 'yum::elff': enable => false }
>
> > }
> > -
> > #Class which has yum::repo define
> > class yum {
>
> >  file { "/etc/yum.repos.d":
> >    ensure  => directory,
> >    purge   => true,
> >    recurse => true,
> >    owner   => 'root',
> >    group   => 'root',
> >    mode    => 0755,
> >    source  => "puppet:///yum/yum.repos.d"
> >  }
>
> >  define repo ( $descr='absent', $enabled='0', $baseurl='absent',
> > $mirrorlist='absent', $gpgcheck='absent', $gpgkey='absent',
> >                $exclude='absent', $includepkgs='absent' ) {
>
> >    if $gpgkey != 'absent' and ! defined(File["${gpgkey}"]) {
>
> >      $key = "file://${gpgkey}"
>
> >      file { "${gpgkey}":
> >        owner  => root,
> >        group  => root,
> >        mode   => 0444,
> >        source => "puppet:///modules/yum${gpgkey}",
> >        before => Yumrepo["${name}"]
> >      }
>
> >      exec { "rpm --import ${gpgkey}":
> >        path        => "/bin:/sbin:/usr/bin:/usr/sbin",
> >        subscribe   => File["${gpgkey}"],
> >        refreshonly => true
> >      }
>
> >    }
> >    else {
> >      $key = 'absent'
> >    }
>
> >    yumrepo { "${name}":
> >      descr          => $descr,
> >      enabled        => $enabled,
> >      baseurl        => $baseurl,
> >      mirrorlist     => $mirrorlist,
> >      failovermethod => 'priority',
> >      gpgcheck       => $gpgcheck,
> >      gpgkey         => $key,
> >      exclude        => $exclude,
> >      includepkgs    => $includepkgs,
> >      require        => File["/etc/yum.repos.d"]
> >    }
>
> Not sure if this covers all the files in the yum.repos.d directory.
> You can try adding an additional file resource in the define resource
> to avoid the file directory purge performing any action on files
> created by yumrepo resource type:
>
> file { "/etc/yum.repos.d/${name}.repo":
>   ensure => file,
>
> }
>
> Alternatively, I think yumrepo can be modeled as a file using a file
> using ERB template instead of yumrepo resource:
>
> define yum::repo {
>    ...
>
>   file { "/etc/yum.repos.d/${name}.repo":
>     ensure => file,
>     owner => 'root',
>     group => 'root',
>     mode => '0644',
>     source => template('yum/yumrepo.erb')
>   }
>
> }
>
> yumrepo.erb:
> [<%=name%>]
> name=<%=desc%>
> baseurl=<%=baseurl%>
> ...
>
> Thanks,
>
> Nan

-- 
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] Composing a text file with Puppet

[M C]

Hi,

is it possible to push a file (with "source" or "content") and then add
lines without having Puppet to regenerate it every time it runs?
And, how can I add, remove or alter text lines without keeping old contents?
Note: i want resources to be executed only if something actually changes.

Please help, thanks.

Matteo

-- 
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: Check for dead clients

[Nan Liu]

On Tue, Aug 30, 2011 at 9:24 AM, It Dept  wrote:
> Hi,
>
> Can either of these methods send notifications about the problem? Or
> do these need to be manually checked?

The files in vardir/reports are stored in a separate directory under
each hostname with a date time stamp for every puppet agent run, so it
should be straightforward to write a custom notification with that
info.

Thanks,

Nan

-- 
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: howto make file resource purge option aware of other puppet resources managed files

[Nan Liu]

On Mon, Aug 29, 2011 at 7:38 PM, piavlo  wrote:
> Hi Daniel,
>
> it looks indeed that it works in some/most cases - I tried to create a
> minimal test class to check it using only file resources and it works
> as you say - and as I want. So I have to post here one of the actual
> not so minimal use case which depend on the expected behaviour.
>
> -
> #Class to setup specific yum repos
> class ssa::yum {
>
>  class { '::yum': }
>
>  class { 'yum::epel': enable => true }
>  class { 'yum::rpmforge': enable => true }
>  class { 'yum::nixval': enable => true }
>  class { 'yum::cloudera': enable => true }
>
>  class { 'yum::zabbix': enable => false }
>  class { 'yum::elff': enable => false }
>
> }
> -
> #Class which has yum::repo define
> class yum {
>
>  file { "/etc/yum.repos.d":
>    ensure  => directory,
>    purge   => true,
>    recurse => true,
>    owner   => 'root',
>    group   => 'root',
>    mode    => 0755,
>    source  => "puppet:///yum/yum.repos.d"
>  }
>
>  define repo ( $descr='absent', $enabled='0', $baseurl='absent',
> $mirrorlist='absent', $gpgcheck='absent', $gpgkey='absent',
>                $exclude='absent', $includepkgs='absent' ) {
>
>    if $gpgkey != 'absent' and ! defined(File["${gpgkey}"]) {
>
>      $key = "file://${gpgkey}"
>
>      file { "${gpgkey}":
>        owner  => root,
>        group  => root,
>        mode   => 0444,
>        source => "puppet:///modules/yum${gpgkey}",
>        before => Yumrepo["${name}"]
>      }
>
>      exec { "rpm --import ${gpgkey}":
>        path        => "/bin:/sbin:/usr/bin:/usr/sbin",
>        subscribe   => File["${gpgkey}"],
>        refreshonly => true
>      }
>
>    }
>    else {
>      $key = 'absent'
>    }
>
>    yumrepo { "${name}":
>      descr          => $descr,
>      enabled        => $enabled,
>      baseurl        => $baseurl,
>      mirrorlist     => $mirrorlist,
>      failovermethod => 'priority',
>      gpgcheck       => $gpgcheck,
>      gpgkey         => $key,
>      exclude        => $exclude,
>      includepkgs    => $includepkgs,
>      require        => File["/etc/yum.repos.d"]
>    }

Not sure if this covers all the files in the yum.repos.d directory.
You can try adding an additional file resource in the define resource
to avoid the file directory purge performing any action on files
created by yumrepo resource type:

file { "/etc/yum.repos.d/${name}.repo":
  ensure => file,
}

Alternatively, I think yumrepo can be modeled as a file using a file
using ERB template instead of yumrepo resource:

define yum::repo {
   ...

  file { "/etc/yum.repos.d/${name}.repo":
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
source => template('yum/yumrepo.erb')
  }
}

yumrepo.erb:
[<%=name%>]
name=<%=desc%>
baseurl=<%=baseurl%>
...

Thanks,

Nan

-- 
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] Module organization: file serving

[Arnau Bria]

On Tue, 30 Aug 2011 09:44:59 -0400
Nan Liu wrote:

Hi Nan,

> No, files in the manifests directory are not accesible through source
> => puppet:///... The manifests directory is intended to be
> inaccessible to the agent since it contains files that should be
> compiled on the master. 

thanks. now it's clear. What I request is impossible.

> Any reason, you intend to give the agent
> access to the manifests directory instead of using the files
> directory?

No, I simply thought that could be easy to manage files if they are
stored under each subdirectory. Anyway, I'll create a similar
manifests tree under files directory.

> MODULE_PATH
> |-module_name
>|-files
>|-bar
>   |-baz
>|-manifests
>|-foo.pp
>|-bar
>|-bar.pp
> 
> So for the agent to retrieve files/bar/baz:
> source => "${module_name}/bar/baz"

Yep, that's how we current work.

Thanks for your reply.
 
> Thanks,
> Nan
Cheers,
Arnau

-- 
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: Service resource does not turn services off on reboots

[jcbollinger]

Something you are doing is causing your messages to not be threaded
together with each other or with others' messages -- instead, each one
is starting a new thread.  That makes it extremely difficult to track
the discussion, so I hope you can figure out what you're doing and fix
it.  One alternative would be to post via Google Groups's web
interface.

On Aug 29, 10:24 am, Frederiko Costa  wrote:
> Hi,
>
> Thanks for the help.
>
> I do see these services coming back up if I reboot the system. They are
> brought down again when puppet run for the first time. Besides, I have never
> seen Puppet calling chkconfig service off even in the first run, when the
> services were in a up state after the system installation. I wonder if I
> missed something.


Likely you have missed something, for the Service resource works as
advertised on Redhat-family systems for many other people.  Things to
check:

1) Make sure the Puppet agent is successfully retrieving its catalog
from the master.  If it cannot (e.g. if catalog compilation fails on
the master) then the agent will apply the last catalog it did manage
to retrieve, which may not have the expected properties declared for
the resources in question.

2) Make sure the catalog that is applied in fact does declare the
resource properties you expect it to do.  You can do this by looking
at the catalog YAML in the agent's cache.

3) Run chkconfig immediately after a run of the Puppet agent to check
whether the services in question are enabled, and in which runlevels.
This is your guage of whether Puppet did the right thing with respect
to Service's 'enable' property.  For best results, test with a minimal
catalog so that the Puppet run doesn't drag out.

4) Disable Puppet, restart, and immediately run chkconfig after the
system comes up.  Are the services in question still configured as
Puppet left them?  If not, then you have something else competing with
Puppet for control of those resources.  If so, but the services were
started anyway, then something very strange and out-of-spec is going
on.


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.

Re: [Puppet Users] Module organization: file serving

[Nan Liu]

On Tue, Aug 30, 2011 at 5:47 AM, Arnau Bria  wrote:
> On Mon, 29 Aug 2011 10:04:42 -0700
> Nigel Kersten wrote:
>
>> On Mon, Aug 29, 2011 at 8:23 AM, Arnau Bria  wrote:
>
> Hi Nigel,
>
> I think my question was not clear:
>
>> > MODULE_PATH
>> > |-module_name
>> >        |-files
>> >        |-manifests
>> >                |-foo.pp
>> >                |-bar
>> >                        |-bar.pp
>> >
>> >
>> > My question is: is there a similar behaviour for file serving? May I
>> > create a file dir under bar directory and serve files from there?
>> >
>>
>> Yes.
>>
>> $module_name/files/foo/bar/baz
>>
>> is
>>
>> puppet:///modules/$module_name/foo/bar/baz
>
> and:
>
> $module_name/manifests/bar/files/baz?
>
> is accessible?

No, files in the manifests directory are not accesible through source
=> puppet:///... The manifests directory is intended to be
inaccessible to the agent since it contains files that should be
compiled on the master. Any reason, you intend to give the agent
access to the manifests directory instead of using the files
directory?

MODULE_PATH
|-module_name
   |-files
   |-bar
  |-baz
   |-manifests
   |-foo.pp
   |-bar
   |-bar.pp

So for the agent to retrieve files/bar/baz:
source => "${module_name}/bar/baz"

Thanks,

Nan

-- 
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: howto make file resource purge option aware of other puppet resources managed files

[jcbollinger]

You put your finger on it when you wrote "It will purge files managed
by other puppet resources in the same directory," but Daniel missed
your meaning, as did I on my first reading.

You have tripped over a subtlety in the meaning of File's 'purge'
parameter: it removes files that are not managed *via File
resources*.  It is not aware of files that are managed via other
resources.  You might consider filing a ticket about this, but do
check first whether there's an existing one (i.e. I didn't).

On the other hand, one reason you've run into trouble is that you're
mixing levels of resource abstraction and effectively managing the
same physical resources through two independent paths.  To ensure that
only the repos managed via Puppet are in fact present at all, you
should be using the Resources metaresource:

resources { 'yumrepo': purge => true }

That says more directly what you seem really to want to say, without
assuming any particular back-end storage for repository declarations.
Moreover, it should do the right thing if you happen to end up with
managed and unmanaged repositories declared in the same file.  (Note:
do not set the 'purge' parameter for File['/etc/yum.repos.d'], or set
it to 'false'.)


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.

[Puppet Users] Re: Check for dead clients

[It Dept]

Hi,

Can either of these methods send notifications about the problem? Or
do these need to be manually checked?

-- 
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] Check for dead clients

[Nan Liu]

On Tue, Aug 30, 2011 at 9:12 AM, It Dept  wrote:
> Hello,
>
> Is there a built in way to get notifications about clients which have
> not updated in a defined time period?

Dashboard can provide this information, and you can also monitor
vardir/reports if you have store reports enabled.

Thanks,

Nan

-- 
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] Check for dead clients

[It Dept]

Hello,

Is there a built in way to get notifications about clients which have
not updated in a defined time period?

For example, if a client is configured to poll the master every hour,
and 2 hours elapse without the client polling the master, is there a
way to have the master inform us of this failure?

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-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] Module organization: file serving

[Arnau Bria]

On Mon, 29 Aug 2011 10:04:42 -0700
Nigel Kersten wrote:

> On Mon, Aug 29, 2011 at 8:23 AM, Arnau Bria  wrote:

Hi Nigel,

I think my question was not clear:
 
> > MODULE_PATH
> > |-module_name
> >|-files
> >|-manifests
> >|-foo.pp
> >|-bar
> >|-bar.pp
> >
> >
> > My question is: is there a similar behaviour for file serving? May I
> > create a file dir under bar directory and serve files from there?
> >
> 
> Yes.
> 
> $module_name/files/foo/bar/baz
> 
> is
> 
> puppet:///modules/$module_name/foo/bar/baz

and:

$module_name/manifests/bar/files/baz?

is accessible?

Cheers,
Arnau

-- 
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] Some beginner's questions...

[Francis GALIEGUE]

On Mon, Aug 29, 2011 at 19:36, Daniel Pittman  wrote:
> On Mon, Aug 29, 2011 at 00:51, Martin Alfke  wrote:
>> On 08/29/2011 09:10 AM, Francis GALIEGUE wrote:
>>>
>>> First, we want to use push from the server, not pull from the clients:
>>> is that feasible?
>>
>> Yes, that is possible.
>> The client has to run in listen mode.
>> On the master you use puppet kick 
>> http://docs.puppetlabs.com/man/kick.html
>
> That really only triggers the client to poll the server.  Out of the
> box, it isn't possible to use a server push mode, though you can fake
> it by triggering poll on demand using any number of tools.
> (MCollective, for example, is pretty awesome at doing this, and I used
> that quite frequently at my previous job.)
>
> Why do you want to do this?  Perhaps there is a better way to achieve
> the outcome you are after?
>

Well, we have an Apache/Tomcat setup which serves 50+ sites total, a
part of which is production and the other testing. Right now we have
tools on Apache which handles upgrades for one particular site. What
we want to do is having puppet manage all this instead.

We have trouble enough writing the modules to begin with and I admit I
have never looked at MCollective, though I do know the name :p

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

-- 
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.