[Puppet Users] Newbie question: how to handle prompts from packages?

[Rachel]

For example, I've installed puppet on ubuntu. Say I want to use it to
install an ubuntu package like moodle or mysql-server, puppet is
hanging in the background waiting for a response to a question.

(Installation of these packages normally interacts with the user to
ask for passwords, etc)

So how do I configure puppet to accommodate this?

I've searched through the docs, and googled, but can't find any
references to this, so any pointers would be gratefully received.

TIA
Rachel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Newbie question: how to handle prompts from packages?

[James Turnbull]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/01/10 8:52 PM, Rachel wrote:
> For example, I've installed puppet on ubuntu. Say I want to use it to
> install an ubuntu package like moodle or mysql-server, puppet is
> hanging in the background waiting for a response to a question.
> 
> (Installation of these packages normally interacts with the user to
> ask for passwords, etc)
> 

See the responsefile attribute of the package type.

http://docs.reductivelabs.com/references/stable/type.html#package

Regards

James Turnbull

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS2ARZSFa/lDkFHAyAQKTWQgAnb++buLTtwE08sleDK2xI3wo0hMIagxo
cEz59r88wxx3mGJ8f7O6KE0UU68bRfS+K48awBukjMwXTJ3wmuq85YEG8hy9pljZ
iEsVbQsqRr6lOywIxNRnrp9lfR0t4hYF7tG00Hn5xquQPOSObFIXR2kb/RpsD9J8
C33UgylJPRgQn4QFAqfrduX2w1S0SWaXfw1ZQm/DOpHy4tBSK6gZht/jqcj13iMM
Et+dNAVv65qAzWqj2YHSqfy1MnlVAnm55a8Oc0POl/V1ElbPDwfJQ+LOWgpnCRtQ
zG0AdPvjr+gpb6GErm7iPDiWuF9qyvctyywdOwSH/tu8O1vn9vXj6w==
=zXSW
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Newbie question: how to handle prompts from packages?

[Rachel Willmer]

Thanks, that's exactly what I was looking for.
Rachel

P.S. James, I ordered your book yesterday from Amazon, so hopefully
all my other newbie questions will be answered there :-)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: New Puppet Documentation Site

[Bryan Schneiders]

While the new documentation site is "pretty", I agree with the other
posts that the font is way too big.  I'm using Firefox 3.5.6 in Fedora
12.  I find the new documentation site to take much longer to
navigate, both between pages and on a page.  The load times are fine,
the layout is in my opinion is highly inefficient and the same
information that existed in the old wiki is much more spread out.

I only took the time to find this thread because the old pages were
damaged by the change.

For example:

The old wiki page looks like it did yesterday:
http://reductivelabs.com/trac/puppet/wiki

But the type reference page redirects out of the wiki to an ugly and
older archived version:  (all of the nagios types are flooding the
document again)
http://reductivelabs.com/trac/puppet/wiki/TypeReference

I would be very happy if we could get the same copy of that page back
that we had earlier this week.  The old wiki is much more efficient
for me to navigate.

I appreciate your effort on the new documentation site.

On Jan 14, 11:28 am, Teyo Tyree  wrote:
> Hello,
>
> For sometime now, we have being considering how to improve on the current
> Puppet documentation available in the existing wiki.  We knew that we needed
> to provide some curated documentation and that some of the curated
> documentation would be directly sourced from the wiki.  We also wanted to
> encourage community engagement in the maintenance of the new documentation,
> because we believe strongly that community involvement makes better
> documentation.
>
> Bruce Williams took the time to migrate some of the current wiki pages into
> our new documentation format.  He also setup the infrastructure to maintain
> the docs.  Basically, we are storing the documents in a public git repo and
> treating the documentation just like any other community project.  This
> serves two essential purposes.  Firstly, Reductive Labs will play an active
> roll in shepherding the documentation.  This is not unlike the roll we
> currently play in managing our other projects.  Secondly, we hope that this
> will be a nice way for new community members to become familiar with our bug
> reporting and contribution processes.
>
> We have moved the following documentation over to the new
> docs.reductivelabs.com location:
>
> http://docs.reductivelabs.com/guides/introduction.htmlhttp://docs.reductivelabs.com/guides/installation.htmlhttp://docs.reductivelabs.com/references
>
> Notice that the reference documentation is now archived for older releases.
>
> We know that this it is not yet comprehensive documentation but it is a
> start.  If you would like to contribute or provide feedback, we have
> outlined that process as well.
>
> http://docs.reductivelabs.com/contribute.html
>
> For the time being, the old wiki will remain essentially unchanged.  We will
> gradually move appropriate content into docs.   We will continue to provide
> a wiki for community documentation.  We just believe that there is room for
> curated documentation as well. We expect that wiki documentation will be a
> place where the community develops new documentation that once vetted may be
> appropriate for the docs.  Or a place for detailed "how to" style docs about
> a specific aspect of configuration management.  As always, your feedback is
> encouraged.
>
> Cheers,
> Teyo
>
> --
> Teyo Tyree ::www.reductivelabs.com:: +1.615.275.5066

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: New Puppet Documentation Site

[John Lyman]

It would be nice if the page titles weren't all "Puppet Docs."  When I
have multiple pages open in separate tabs, it's difficult to find the
page I want.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: New Puppet Documentation Site

[Peter Meier]

It would be nice if the page titles weren't all "Puppet Docs."  When I
have multiple pages open in separate tabs, it's difficult to find the
page I want.


The best idea is to fill feature requests on:  
http://projects.reductivelabs.com/projects/puppet-docs


I assume it's pretty hard to track feature requests in various mail threads.

cheers pete

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Using Git to distribute Puppet configs

[John Arundel]

Hi,

Stephen would never mention it himself, he's too modest, but he's done
a great write-up of how he uses Git (or other DVCS) to distribute
manifests instead of using a Puppetmaster. It's quite flexible and
powerful (you can use a post-receive hook on the remote repos to run
Puppet whenever a new config is pushed out, for example). It's an
approach to Puppet scaling I've not seen before - I really like this
idea, so I'd be interested to know if anyone else has done something
similar, and what you think about Stephen's scheme:

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

Regards,
John
-- 
Bitfield Consulting: we make software that makes things work
http://bitfieldconsulting.com/

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Newbie question: how to handle prompts from packages?

[Eric Gerlach]

On Wed, Jan 27, 2010 at 09:11:49PM +1100, James Turnbull wrote:
> See the responsefile attribute of the package type.
> 
> http://docs.reductivelabs.com/references/stable/type.html#package

You can do that now?  Oh.  That makes me happy, and I love Debian :-)

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerl...@feds.uwaterloo.ca

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] recurse => true

[Anchi Zhang]

On Tue, Jan 26, 2010 at 2:15 PM, Anchi Zhang  wrote:

>
>
>  >>> My fileserver.conf contains
>> >>>
>> >>> [files-solaris]
>> >>> path /etc/puppet/manifests/files/solaris
>> >>> allow *
>> >>>
>> >>> and
>> >>>
>> >>> puppetmaster# ls /etc/puppet/manifests/files/solaris/etc
>> >>> motd   nsswitch.conf  pam.conf   resolv.conf
>> >>> I would like to have these files in /etc of all solaris hosts.
>> >> and so if you remove motd in /etc/puppet/manifests/files/solaris/etc
>> >> you'd like to have /etc/motd removed as well?
>> >>
>> > No, no removing.  Files are to be copied over if the source's version is
>> > different from that of the target.  This is the way I had files in sync
>> in
>> > cfengine.
>> >
>>
>> well, then I don't understand what you meant with:
>>
>> "But, if "/motd" is removed, files under /etc would not get updated."
>>
> I meant to say that, if a file name is specified such as /etc/motd, the
> config would work but, if /etc is specified with recurse => true to update
> all the files in files-solaris/etc, the config would not work.
>
>
>>
>> Something like that will work:
>>
>> node default { include solaris }
>> class solaris {
>>  etc_file{['motd','nsswitch.conf','pam.conf','resolv.conf']: }
>>
>>  define etc_file(){
>>file { "/etc/${name}":
>>  source => "puppet:///files-solaris/etc/${name}",
>>}
>>  }
>> }
>>
>> but this approach is not very puppet-like nor will it scale.
>
>
> This is what I try to avoid.  If a file/director gets added to
> files-solaris/etc such as inet/ntp.conf as a later time, no puppet config
> change would be necessary.
>

And my config was pretty much a direct copy from James Turnbull's book which
uses /etc/pam.d as an example.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Using Git to distribute Puppet configs

[Atha Kouroussis]

Hi John, 
I read the blog post and although an interesting approach, I can see several 
shortcomings, namely:
- Lack of external node classifier: how do you control/specify which node 
applies which modules?
- Anything apart from a DVCS to do deployment (i.e. subversion) would be 
madness. And even with git I think it can get out of control really fast
- Each node has a copy of the entire repository of modules and classes which 
makes it in my opinion a security risk.

I agree with the fact that puppet's SSL config/setup can be a real PITA, 
especially when dealing with multiple locations/domains.

Cheers,
Atha
On Jan 27, 2010, at 12:21 , John Arundel wrote:

> Hi,
> 
> Stephen would never mention it himself, he's too modest, but he's done
> a great write-up of how he uses Git (or other DVCS) to distribute
> manifests instead of using a Puppetmaster. It's quite flexible and
> powerful (you can use a post-receive hook on the remote repos to run
> Puppet whenever a new config is pushed out, for example). It's an
> approach to Puppet scaling I've not seen before - I really like this
> idea, so I'd be interested to know if anyone else has done something
> similar, and what you think about Stephen's scheme:
> 
> http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control
> 
> Regards,
> John
> -- 
> Bitfield Consulting: we make software that makes things work
> http://bitfieldconsulting.com/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] up2date + arch

[James Cammarata]

On Tue, 19 Jan 2010 13:07:21 -0800 (PST), James  wrote:
> I'm having an issue using package resources on RHEL 4 systems using
> up2date with RHN.  I need to ensure that libacl.i386 is installed on a
> x86_64 system, however the up2date provider does not seem to like the
> yum syntax for specifying arch, and there doesn't seem to be any other
> method for doing so.
> 
> I found this thread, http://projects.reductivelabs.com/issues/2043,
> that is the same issue, but apparently no progress has been made on it
> in 10 months.  Considering there are a large number of RHEL4 / Centos4
> boxes around, I am surprised that a solution for this has not been
> implemented yet.
> 
> Does anyone have a solution for this?  Can I extend the package
> resource somehow to allow up2date to handle the arch properly?

Never saw any response to this, has anyone run into this issue besides
me?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] recurse => true

[Peter Meier]

Something like that will work:

node default { include solaris }
class solaris {
 etc_file{['motd','nsswitch.conf','pam.conf','resolv.conf']: }

 define etc_file(){
   file { "/etc/${name}":
 source => "puppet:///files-solaris/etc/${name}",
   }
 }
}

but this approach is not very puppet-like nor will it scale.



This is what I try to avoid.  If a file/director gets added to
files-solaris/etc such as inet/ntp.conf as a later time, no puppet config
change would be necessary.



And my config was pretty much a direct copy from James Turnbull's book which
uses /etc/pam.d as an example.


the reason why I say that it doesn't scale is that for example if the  
ntp file changes you'd like to to restart the ntp service if the ntp  
config changes and so on. Anyway the idea is to organize things that  
belongs together, for example for ntp, the package, the service and  
the config file in one module, which encapsulates the resource ntp  
you'd like to manage.
Further if you remove something in the source folder it won't be  
removed on the server, you have to do that anyway manually.


Anyway the following receipe should do what you want:

node default { include solaris }
class solaris {
 file { "/etc":
   source => "puppet:///files-solaris/etc/",
   ensure => directory,
   recurse => true,
 }
}

however again, I really don't like the idea of managing /etc in one  
big piece. But to start and try things out you could do that.


If you still encounter the error, please post the output with --trace  
and let us know about server and client versions.


cheers pete

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] recurse => true

[Anchi Zhang]

>
> the reason why I say that it doesn't scale is that for example if the ntp
>> file changes you'd like to to restart the ntp service if the ntp config
>> changes and so on. Anyway the idea is to organize things that belongs
>> together, for example for ntp, the package, the service and the config file
>> in one module, which encapsulates the resource ntp you'd like to manage.
>> Further if you remove something in the source folder it won't be removed
>> on the server, you have to do that anyway manually.
>>
>> Anyway the following receipe should do what you want:
>>
>> node default { include solaris }
>> class solaris {
>>  file { "/etc":
>>   source => "puppet:///files-solaris/etc/",
>>   ensure => directory,
>>   recurse => true,
>>  }
>> }
>>
>> however again, I really don't like the idea of managing /etc in one big
>> piece. But to start and try things out you could do that.
>>
>> If you still encounter the error, please post the output with --trace and
>> let us know about server and client versions.
>
>
Node and class:

node default { include solaris }
class solaris {
file { "/etc":
source => "puppet:///files-solaris/etc",
recurse => true,
ensure => directory,
}
}
Solaris 10 puppet master trace:

notice: Starting Puppet server version 0.25.2
info: mount[files-solaris]: allowing * access
info: Inserting default '~ ^/catalog/([^/]+)$'(auth) acl because
/etc/puppet/auth.conf doesn't exist
info: Inserting default '/file'(non-auth) acl because /etc/puppet/auth.conf
doesn't exist
info: Inserting default '/certificate_revocation_list/ca'(auth) acl because
/etc/puppet/auth.conf doesn't exist
info: Inserting default '/report'(auth) acl because /etc/puppet/auth.conf
doesn't exist
info: Inserting default '/certificate/ca'(non-auth) acl because
/etc/puppet/auth.conf doesn't exist
info: Inserting default '/certificate/'(non-auth) acl because
/etc/puppet/auth.conf doesn't exist
info: Inserting default '/certificate_request'(non-auth) acl because
/etc/puppet/auth.conf doesn't exist
info: Expiring the node cache of 1km-admin.reinternal.com
info: Not using expired node for 1km-admin.reinternal.com from cache;
expired at Wed Jan 27 10:35:47 -0600 2010
info: Caching node for 1km-admin.reinternal.com
notice: Compiled catalog for 1km-admin.reinternal.com in 0.08 seconds
info: mount[files-solaris]: allowing * access
Solaris 10 puppet client trace:

notice: Starting Puppet client version 0.25.2
info: Caching catalog for 1km-admin.reinternal.com
info: Applying configuration version '1264610148'
/usr/local/lib/ruby/site_ruby/1.8/puppet/file_serving/metadata.rb:68:in
`collect'
/usr/local/lib/ruby/site_ruby/1.8/puppet/file_serving/terminus_helper.rb:20:in
`path2instances'
/usr/local/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:85:in `collect'
/usr/local/lib/ruby/site_ruby/1.8/puppet/file_serving/terminus_helper.rb:17:in
`each'
/usr/local/lib/ruby/site_ruby/1.8/puppet/file_serving/terminus_helper.rb:17:in
`collect'
/usr/local/lib/ruby/site_ruby/1.8/puppet/file_serving/terminus_helper.rb:17:in
`path2instances'
/usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/direct_file_server.rb:21:in
`search'
/usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/file_metadata/file.rb:20:in
`search'
/usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:240:in
`search'
/usr/local/lib/ruby/site_ruby/1.8/puppet/indirector.rb:59:in `search'
/usr/local/lib/ruby/site_ruby/1.8/puppet/type/file.rb:595:in
`perform_recursion'
/usr/local/lib/ruby/site_ruby/1.8/puppet/type/file.rb:547:in `recurse_local'
/usr/local/lib/ruby/site_ruby/1.8/puppet/type/file.rb:477:in `recurse'
/usr/local/lib/ruby/site_ruby/1.8/puppet/type/file.rb:385:in `eval_generate'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in `send'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in
`generate_additional_resources'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:193:in
`eval_generate'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:240:in
`eval_children_and_apply_resource'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:207:in
`eval_resource'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:296:in `evaluate'
/usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:403:in `thinmark'
/usr/local/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:402:in `thinmark'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:295:in `evaluate'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:289:in `collect'
/usr/local/lib/ruby/site_ruby/1.8/puppet/transaction.rb:289:in `evaluate'
/usr/local/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:153:in `run'
/usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:178:in `benchmark'
/usr/local/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:177:in `benchmark'
/usr/local/

Re: [Puppet Users] Using Git to distribute Puppet configs

[Thomas Bellman]

Atha Kouroussis wrote:


- Lack of external node classifier: how do you control/specify which node
applies which modules?


You would likely use 'node' statements in your manifests.

But I think you can use external_nodes from stand-alone puppet as well.
You would of course need to make sure that the external nodes script
and whatever data files it needs are part of the repository you send out
to the nodes.


- Each node has a copy of the entire repository of modules and classes
which makes it in my opinion a security risk.


Don't put passwords and private keys in your manifests.

If you have secrets due to NDAs or other commercial concerns, then it might
be a bad idea to manage such things with Puppet and distribute your manifests
this way.  If it is a secret that you are using product X in department Y,
then you night not want that information on a laptop belonging to department
Z that might be stolen.  But there are many organisations that don't need to
keep that information secret (and if they think they do due to security
concerns, they likely have problems anyway).  Some organisations do have
such secrets, though, and they need to evaluate the risks before doing it.


/Bellman

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] recurse => true

[Peter Meier]

Node and class:

node default { include solaris }
class solaris {
file { "/etc":
source => "puppet:///files-solaris/etc",
recurse => true,
ensure => directory,
}
}
Solaris 10 puppet master trace:

notice: Starting Puppet server version 0.25.2


could it be that somewhere in /etc there is a broken symlink? Note: as  
you are recursively managing /etc as far as I remember every file in  
/etc is checked (hint: another reason why this approach doesn't  
scale)...


This smeels like #3001 [1] maybe you could test with 0.25.4rc3?

cheers pete

[1] http://projects.reductivelabs.com/issues/3001

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Using Git to distribute Puppet configs

[Nigel Kersten]

On Wed, Jan 27, 2010 at 7:59 AM, Atha Kouroussis wrote:

> Hi John,
> I read the blog post and although an interesting approach, I can see
> several shortcomings, namely:
> - Lack of external node classifier: how do you control/specify which node
> applies which modules?
>

We don't do things this way (although I've considered it often) but at the
same time have only the default node defined.

We use facts to determine what kind of attributes a machine possesses, and
the selectively choose which modules are applied based upon that.

node default { include base }

and then modules/base/manifests/init.pp is where all the logic lives.

I like having my clients be self-organizing as much as possible.

- Anything apart from a DVCS to do deployment (i.e. subversion) would be
> madness. And even with git I think it can get out of control really fast
> - Each node has a copy of the entire repository of modules and classes
> which makes it in my opinion a security risk.
>
> I agree with the fact that puppet's SSL config/setup can be a real PITA,
> especially when dealing with multiple locations/domains.
>
> Cheers,
> Atha
> On Jan 27, 2010, at 12:21 , John Arundel wrote:
>
> > Hi,
> >
> > Stephen would never mention it himself, he's too modest, but he's done
> > a great write-up of how he uses Git (or other DVCS) to distribute
> > manifests instead of using a Puppetmaster. It's quite flexible and
> > powerful (you can use a post-receive hook on the remote repos to run
> > Puppet whenever a new config is pushed out, for example). It's an
> > approach to Puppet scaling I've not seen before - I really like this
> > idea, so I'd be interested to know if anyone else has done something
> > similar, and what you think about Stephen's scheme:
> >
> >
> http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control
> >
> > Regards,
> > John
> > --
> > Bitfield Consulting: we make software that makes things work
> > http://bitfieldconsulting.com/
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> > To post to this group, send email to puppet-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How do I use a desktop client as puppet master?

[Markus Falb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/01/2010 13:06, Mr Gabriel wrote:
> Fully Qualified Domain Name seems to be a requirement for puppet master
> server. I was expecting to run into issues say around 2/3 of the way
> through, not at step one!
> 
> So I guess my question is, is it possible to use a desktop system, with
> no FQDN as the puppet master server?
> 

I do something like that (simplified):
ssh -R 8140:localhost:8140 r...@client puppetd --test --server localhost

This was not because of missing fqdn, but of firewall and security
considerations. Config is not pulled by clients but pushed by Server
that way. Daemon on client has not to be run, saving Resources. I do not
that very big puppet Installation though.

- -- 
best regards,
markus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkteeOQACgkQYoWFBIJE9eXg8gCZAd+KraoKJIuM4HIy8mD6gjkw
e44AnREpKOAZMgktyoyJzAy5FIaYWI96
=P/Rj
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] recurse => true

[Anchi Zhang]

On Wed, Jan 27, 2010 at 11:06 AM, Peter Meier wrote:

>  Node and class:
>>
>> node default { include solaris }
>> class solaris {
>>file { "/etc":
>>source => "puppet:///files-solaris/etc",
>>recurse => true,
>>ensure => directory,
>>}
>> }
>> Solaris 10 puppet master trace:
>>
>> notice: Starting Puppet server version 0.25.2
>>
>
> could it be that somewhere in /etc there is a broken symlink? Note: as you
> are recursively managing /etc as far as I remember every file in /etc is
> checked (hint: another reason why this approach doesn't scale)...
>
> This smeels like #3001 [1] maybe you could test with 0.25.4rc3?
>
> cheers pete
>
> [1] http://projects.reductivelabs.com/issues/3001


The following test worked and may have proved your theory.  Thank you very
much for the help.

node default { include solaris }
class solaris {
file { "/etc/inet":
source => "puppet:///files-solaris/etc/inet",
recurse => true,
}
}

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] err: Could not call list: header too long

[Jason Amato]

Getting this error:
err: Could not call list: header too long
when running puppetca commands on master.

There is not a disk space issue.

On the puppet master server, /var filled up to 100% during the night.
Now it's fine, down to 25% used.
I rebooted server too

Any fixes?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: err: Could not call list: header too long

[Jason Amato]

some debug info:
# puppetca -l -d
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does
not exist
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
dscl does not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
debug: /File[/var/puppet/ssl/ca/ca_key.pem]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/public_keys]: Autorequiring File[/var/
puppet/ssl]
debug: /File[/var/puppet/ssl/ca/signed]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/ca]: Autorequiring File[/var/puppet/ssl]
debug: /File[/var/puppet/run]: Autorequiring File[/var/puppet]
debug: /File[/var/puppet/ssl/public_keys/nydcvmueng03.cbs.net.pem]:
Autorequiring File[/var/puppet/ssl/public_keys]
debug: /File[/var/puppet/ssl/ca/ca_pub.pem]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/certs/nydcvmueng03.cbs.net.pem]:
Autorequiring File[/var/puppet/ssl/certs]
debug: /File[/var/puppet/ssl/crl.pem]: Autorequiring File[/var/puppet/
ssl]
debug: /File[/var/puppet/ssl/ca/private/ca.pass]: Autorequiring File[/
var/puppet/ssl/ca/private]
debug: /File[/var/puppet/lib]: Autorequiring File[/var/puppet]
debug: /File[/var/puppet/facts]: Autorequiring File[/var/puppet]
debug: /File[/var/puppet/ssl/ca/ca_crl.pem]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/state]: Autorequiring File[/var/puppet]
debug: /File[/var/puppet/ssl/ca/requests]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/private_keys]: Autorequiring File[/var/
puppet/ssl]
debug: /File[/var/puppet/ssl/ca/serial]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/certs/ca.pem]: Autorequiring File[/var/
puppet/ssl/certs]
debug: /File[/var/puppet/ssl]: Autorequiring File[/var/puppet]
debug: /File[/var/puppet/ssl/ca/private]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/ca/inventory.txt]: Autorequiring File[/
var/puppet/ssl/ca]
debug: /File[/var/puppet/ssl/ca/ca_crt.pem]: Autorequiring File[/var/
puppet/ssl/ca]
debug: /File[/var/puppet/ssl/private]: Autorequiring File[/var/puppet/
ssl]
debug: /File[/var/puppet/ssl/certificate_requests]: Autorequiring File
[/var/puppet/ssl]
debug: /File[/var/puppet/log]: Autorequiring File[/var/puppet]
debug: /File[/var/puppet/ssl/certs]: Autorequiring File[/var/puppet/
ssl]
debug: /File[/var/puppet/ssl/private_keys/nydcvmueng03.cbs.net.pem]:
Autorequiring File[/var/puppet/ssl/private_keys]
debug: Finishing transaction 23502383628884 with 0 changes
err: Could not call list: header too long

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] up2date + arch

[Carl Caum]

Unfortunately even the yum provider sucks at this too.  It may have been fixed 
recently, but I don't think so since the problem exists in how rpm reports back 
queries for available packages.  I have to solve this with an exec. .  You 
could do something similar to:

exec {"install libacl.i386":
command => "up2date --arch i386 libacl",
onlyif => "rpm -qa libacl.i386 | grep 'libacl' ";
}

On Jan 27, 2010, at 10:17 AM, James Cammarata wrote:

> 
> On Tue, 19 Jan 2010 13:07:21 -0800 (PST), James  wrote:
>> I'm having an issue using package resources on RHEL 4 systems using
>> up2date with RHN.  I need to ensure that libacl.i386 is installed on a
>> x86_64 system, however the up2date provider does not seem to like the
>> yum syntax for specifying arch, and there doesn't seem to be any other
>> method for doing so.
>> 
>> I found this thread, http://projects.reductivelabs.com/issues/2043,
>> that is the same issue, but apparently no progress has been made on it
>> in 10 months.  Considering there are a large number of RHEL4 / Centos4
>> boxes around, I am surprised that a solution for this has not been
>> implemented yet.
>> 
>> Does anyone have a solution for this?  Can I extend the package
>> resource somehow to allow up2date to handle the arch properly?
> 
> Never saw any response to this, has anyone run into this issue besides
> me?
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: err: Could not call list: header too long

[Jason Amato]

all fixed,

had to remove 0 byte file from directory /var/puppet/ssl/ca/requests

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: err: Could not call list: header too long

[Jason Amato]

Yeah, I fixed it!

I removed some 0 byte certificate request files in dir /var/puppet/ssl/
ca/requests.
That did the trick.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] up2date + arch

[James Cammarata]

On Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum  wrote:
> Unfortunately even the yum provider sucks at this too.  It may have been
> fixed recently, but I don't think so since the problem exists in how rpm
> reports back queries for available packages.  I have to solve this with
an
> exec. .  You could do something similar to:
> 
> exec {"install libacl.i386":
> command => "up2date --arch i386 libacl",
> onlyif => "rpm -qa libacl.i386 | grep 'libacl' ";
> }

Yeah, I was hoping to avoid using an exec, but it looks like this would be
the easiest solution to fix it immediately.  I haven't had any issues on
RHEL5 using the yum provider, it likes the .arch syntax well enough.

Thanks!

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] help for simple patch

[Arnauld]

Hi,

in every classes I created, I defined a variable (named $version) to
include a kind of versionning inside them.

In puppetd sources, around network/client/master.rb:293 , the
'setclasses' function log the classes in a 'classfile' (here :
$statedir/classes.txt). I'd just like to add classes $version numbers
in that file.

Anyone know how to access a variable inside a class ?

Regards,

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] up2date + arch

[Carl Caum]

Make extra sure that's true.  I found it won't give you an error but the 
package still won't always be installed. 

On Jan 27, 2010, at 12:05 PM, James Cammarata wrote:

> 
> On Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum  wrote:
>> Unfortunately even the yum provider sucks at this too.  It may have been
>> fixed recently, but I don't think so since the problem exists in how rpm
>> reports back queries for available packages.  I have to solve this with
> an
>> exec. .  You could do something similar to:
>> 
>> exec {"install libacl.i386":
>>command => "up2date --arch i386 libacl",
>>onlyif => "rpm -qa libacl.i386 | grep 'libacl' ";
>> }
> 
> Yeah, I was hoping to avoid using an exec, but it looks like this would be
> the easiest solution to fix it immediately.  I haven't had any issues on
> RHEL5 using the yum provider, it likes the .arch syntax well enough.
> 
> Thanks!
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] help for simple patch

[Peter Meier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> in every classes I created, I defined a variable (named $version) to
> include a kind of versionning inside them.
> 
> In puppetd sources, around network/client/master.rb:293 , the
> 'setclasses' function log the classes in a 'classfile' (here :
> $statedir/classes.txt). I'd just like to add classes $version numbers
> in that file.
> 
> Anyone know how to access a variable inside a class ?


there is the config_version option
http://docs.reductivelabs.com/references/stable/configuration.html#config-version
which gives you the possibility to give the possibility to generate a
certain version for the current used manifests.

this should be sufficient to get what you like. I don't see why you'd
like to have a per class version...

cheers pete
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktgsI8ACgkQbwltcAfKi3/wPACgitgAxlnwAqeRcdJ9OVRn6DpB
UvoAn3Btqpo9JORNUgA1Alt+Eqmf1ALJ
=vO6b
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] help for simple patch

[Scott Smith]

On 1/27/10 12:28 PM, Arnauld wrote:

Anyone know how to access a variable inside a class ?



I and many others have overcome this by using Puppet environments. If I make a change to a module, I 
simply push out another environment and tell clients that need the change to use that environment.


Also I believe there is work to implement module or class metadata which may provide what you're 
looking for--but I'm not sure how far off that is.


-scott

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Disabling automountd on Solaris10.

[Martin Englund]

Tanaka-san!

On Jan 27, 3:57 am, Nobuchika Tanaka  wrote:

> [What I want to Know]
> 1.What "Unmanageable state 'online*' on service autofs" means?
>
When svcs(1) shows an asterisk at the end of the state, it means it is
in transition.

What is happening is that puppet runs "svcadm disable autofs" and then
checks the state before autofs has transitioned from enabled to online
to offline.

> 2.What should I do to avoid this error.
>
You can't - you'll have to wait for this bug to be fixed:


cheers,
/Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Disabling automountd on Solaris10.

[Nobuchika Tanaka]

Mr.Martin.

Thank you for replying.

Thanks to your answer, I understand situation of this problem.
Until this issue is resolved, I will disable automountd in another
way.
On Jan 28, 7:34 am, Martin Englund  wrote:

Nobuchika Tanaka

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Comments on #3120 - chained CAs for issuing certs?

[Eric Sorenson]

I think my bug writeup on #3120 is less than wonderful but I wanted to point it 
up to the list here in hope of inspiring further comment.

The situation is that I followed first Ohad's doc on PuppetScalability, then 
Jeff McCune's MultipleCertificateAuthorities writeup, to no avail. I tried both 
following the directions and then tweaking things which seemed to be wrong (of 
which #3120 is one offshoot) and got no love.  Puppet doesn't seem to want to 
verify a multi-level cert, even when all the CA certificates are available to 
it concatenated together in $ssldir/certs/ca.crt.  ('openssl verify -CAfile 
ca.crt' returns OK)

Ultimately I gave up, like Paul L's thread "SSL Makes My Brain Bleed", my brain 
bled too and I ended up following his hard-fought wisdom from 

http://groups.google.com/group/puppet-users/msg/89b75ebe91c5985b

I.e. Setup one host to be the CA, set ca=false on the other puppetmasters, and 
use puppetd --ca_server=puppetca on initial run to point the clients at it.  I 
sort of feel like I should have done this last week and saved much 
tooth-gnashing.

So my question to the larger audience is, has *anybody* really gotten this to 
work? Both the wiki docs are kind of old and, at least in 
MultipleCertificateAuthorities case, have some pretty serious caveats, like 
"This isn't working".  Even Ohad's setup says "Please note that webrick is at 
this time (0.24.4) unable to handle the certs in a correct way to get this 
setup working."

Thanks
-=Eric

-- 
death needs time for what it kills to grow in

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] LDAP users/groups are being mis-interpretted by RAL

[Joel Heenan]

It seems puppet is getting confused regarding ldap users and groups

err:
//Node[foo]/class/File[/var/log/httpd]:
Failed to retrieve current state of resource: Could not find group readonly at
/etc/puppet/svn/manifests/common/common.pp:26

[foo ~]# getent group | grep readonly
readonly:*:4002:user1,user2

[foo ~]# ralsh group readonly
group { 'readonly':
ensure => 'absent'
}

Using Centos 5.4 with Xen, and 389 Directory Server. Puppet version
puppet-0.24.8-4.el5

Is this a known problem? I googled around a bit and found similar
problems but nothing that looked exactly the same.

Thanks

Joel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Comments on #3120 - chained CAs for issuing certs?

[Ohad Levy]

Hi Eric,

I've a working chained CA setup working for a few years now.

what exactly were your problems? did you remember to add the top level CA
pub key?

I'll try to make some time for this issue next week, and to rebuild the ca
setup in a lab.

on a side note, I'm not 100% sure if it make sense to go all of this extra
work instead of using a centralized CA.

cheers,
Ohad

On Thu, Jan 28, 2010 at 9:03 AM, Eric Sorenson  wrote:

> I think my bug writeup on #3120 is less than wonderful but I wanted to
> point it up to the list here in hope of inspiring further comment.
>
> The situation is that I followed first Ohad's doc on PuppetScalability,
> then Jeff McCune's MultipleCertificateAuthorities writeup, to no avail. I
> tried both following the directions and then tweaking things which seemed to
> be wrong (of which #3120 is one offshoot) and got no love.  Puppet doesn't
> seem to want to verify a multi-level cert, even when all the CA certificates
> are available to it concatenated together in $ssldir/certs/ca.crt.
>  ('openssl verify -CAfile ca.crt' returns OK)
>
> Ultimately I gave up, like Paul L's thread "SSL Makes My Brain Bleed", my
> brain bled too and I ended up following his hard-fought wisdom from
>
> http://groups.google.com/group/puppet-users/msg/89b75ebe91c5985b
>
> I.e. Setup one host to be the CA, set ca=false on the other puppetmasters,
> and use puppetd --ca_server=puppetca on initial run to point the clients at
> it.  I sort of feel like I should have done this last week and saved much
> tooth-gnashing.
>
> So my question to the larger audience is, has *anybody* really gotten this
> to work? Both the wiki docs are kind of old and, at least in
> MultipleCertificateAuthorities case, have some pretty serious caveats, like
> "This isn't working".  Even Ohad's setup says "Please note that webrick is
> at this time (0.24.4) unable to handle the certs in a correct way to get
> this setup working."
>
> Thanks
> -=Eric
>
> --
> death needs time for what it kills to grow in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Comments on #3120 - chained CAs for issuing certs?

[Scott Smith]

On 1/27/10 5:03 PM, Eric Sorenson wrote:

Ultimately I gave up, like Paul L's thread "SSL Makes My Brain Bleed", my brain 
bled too and I
ended up following his hard-fought wisdom from

http://groups.google.com/group/puppet-users/msg/89b75ebe91c5985b

I.e. Setup one host to be the CA, set ca=false on the other puppetmasters, and 
use puppetd
--ca_server=puppetca on initial run to point the clients at it.  I sort of feel 
like I should
have done this last week and saved much tooth-gnashing.



This is what I did and it Just Works(tm). I set ca_server in puppet.conf on 
clients, though.

The only annoying part is that if I ever revoke something, I have to distribute the CRL to my 
puppetmasters. Oh well.


-scott

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Odd run timing with facter

[Forrie]

I have a SunFire Solaris/10 64bit system -- it's older, 1U.   I
installed ruby via the "pkg-get" script -- then installed the gems
puppet and facter.   Facter takes a long time to run:

real0m17.863s
user0m1.582s
sys 0m2.188s

That seems very unusual.   I realize I could (and probably should) try
compiling ruby myself on this platform, then test again.  However, I
wonder if anyone else has seen this on Solaris.

Perhaps I could try to compile a 64-bit version of ruby, tho I read of
some problems with that out there.


Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.