Re: [Puppet Users] constraint checking
Hi, On 01/26/2012 08:14 PM, Jo Rhett wrote: One thing about a well-written piece of generic code is that it can be used in many environments. A lot of my modules do things like do I have an external interface or am I behind the firewall? and do different things based on those answers. Likewise, when dealing with software components you could be on a system dedicated to just that one component, or you could be on a Dev/QA box which has dozens of such components installed. The behavior calls for different actions there. what about custom facts, then? On 01/26/2012 08:22 PM, Jo Rhett wrote: You can't import because of redefinitions. You yourself know well and deeply the issues involved with calling the same class from different places with different parameters. It is nearly impossible to get there from here. Have you considered combining class inheritance with parameters? I have found that in many situations, it's extremely helpful to be able to include an unparameterized base class to satisfy dependencies, and allow nodes to include additional subclasses that take care of the gory details. Granted, this approach won't float any boat out there, but potentially helpful in the SSH example you gave. Cheers, Felix -- 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] courier imap/pop not refreshing
On 01/25/2012 04:40 PM, Christopher Wood wrote: Unfortunately I am unable to reproduce this except outside the target virtualized environment, currently unavailable due to resource concerns. So far courier-imap and courier-pop restart as they should elsewhere. I recommend puppet agent --test --noop. -- 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: Puppet security issue?
Thanks Brice, using mod_rpaf fixed the issue! I've also realized why puppet SHOULD NOT rely on the X-Forwarded-For for determining source information to authorize API access. As soon as I had it working with mod_rpaf I performed an API request with a hostname different than the actual machine: malicious host root$ curl -k -H X-Forwarded-For: trustedhost.domain - H Accept: pson https://puppet.domain:8140/production/certificate_statuses/no_key Which worked, not too surprising. So while mod_rpaf DID fix the issue it also didn't secure anything. Alas, one should always make use of puppet client certificate based auth, especially when using a proxy that may or may not muddle with the origination information. Also, for those who find this later: On CentOS 6.x this is available as an RPM in atomic: rpm -Uvh http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/atomic-release-1.0-14.el6.art.noarch.rpm yum -y install mod_rpaf adding the following to the vhost: VirtualHost *:18142 RPAFenable On RPAFsethostname On RPAFproxy_ips 127.0.0.1 Now that I know it works I'll likely build an RPM for the local repo, rather than rely on a lesser known repo. Thanks again, Ryan Bowlby On Jan 26, 11:37 pm, Brice Figureau brice-pup...@daysofwonder.com wrote: On 27/01/12 02:14, Ryan Bowlby wrote: Hi All, I have a two puppet servers using Apache with mod_proxy as the frontend. Similar to what what's described in Pro Puppet. Unfortunately, Apache mod_proxy is passing the puppetca requests using the loopback IP instead of the original source IP. You're not mentioning what stack your master are running. But if they're running on Apache and Passenger, may I suggest using mod_rpaf? This is a bit of a security concern when configuring auth.conf! An example stanza in auth.conf: # allow certificate management on provisioning server without cert path ~ /cert* auth no allow localhost If you instead make this a certname, then it's secure again. With that near the bottom of auth.conf ALL hosts can now perform any API calls matching that path. This is due to puppet using the 127.0.0.1 passed by Apache. I need one of the following: 1. A way to do IP passthrough in apache such that the correct originating IP is used. Configure your mod_proxy to pass the IP in X-Forwarded-For. 2. Puppet to make use of the X-Forwarded-For header if it exists and to fallback in instances where it doesn't. And mod_rpaf is what you need, running in your master apache. Likely the latter is the best method. Please feel free to correct me if I am missing something. I have verified that with the above auth.conf stanza ALL hosts can perform all /cert* related API calls. Additionally here is a log line: 127.0.0.1 - - [27/Jan/2012:00:32:00 +] GET /production/ certificate_statuses/no_key HTTP/1.1 200 343 - curl/7.15.5 (x86_64- redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/ 0.6.5 That's a request from another server. Here are the Apache configs: http://pastebin.com/rDKPSjjy Thanks everyone! Ryan Bowlby -- Brice Figureau My Blog:http://www.masterzen.fr/ -- 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] Compiled catalog arount 70s
Hi everyone, I am using puppet 2.7.9 and ruby 1.8.7 on debian box. I don't a lot of modules right now: just one module that create user + dotfile + ssh key and compiled catalog takes around 70s do I have to worry is that big. Does the compiled time scale with the module number? Do I have to make sure I don't cross a certain limit? Regards, JM -- 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] Exporting local resources
Hi,
the code below will work, but it will not magically transfer file
contents as seen on host A to the master and from there to host B.
Any state you wish puppt to maintain you have to make known to puppet.
If you want puppet to pickup and process any piece of information from
an agent, you will have to write a custom fact for it. (Contents of
large files are ill fit to be shared as custom facts, though.)
HTH,
Felix
On 01/23/2012 06:10 PM, Lorenzo Salvadorini wrote:
Hi all,
can I export a file present on a puppet client not created by puppet itself?
In example:
On host A I have a file /var/www/my_intranet_site/htusers that I like to
have on host B too
class exporter {
@@file { /var/www/my_intranet_site/htusers:
tag = basic_auth_users,
ensure = present,
}
}
class importer {
File | tag == basic_auth_users |
}
host A {
include exporter
}
host B {
include importer
}
Thanks,
L.
--
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: Cross-module dependencies
Hi John, thanks for coming up with such elaborate ideas, your input to this group adds a lot of meat to many discussions. I can agree with a lot of what you wrote, barring the following remarks: On 01/26/2012 06:00 PM, jcbollinger wrote: Modules provide definitions of resources that they own. For the most part, those definitions should be virtual to avoid unnecessary inter- module coupling, but some resources are reasonable to define concretely. Jeff has made a strong point against using virtual resources in modules at all, causing me to shift my own views as well. If I understand him correctly, one of the chief problems is the high probability of accidental collection/realisation of such resources by the end user's manifest. On 01/26/2012 06:48 PM, jcbollinger wrote: I can imagine many -- perhaps most -- resource definitions being replaced or supplemented by constraint declarations. The model is intriguing, but gives me another usability headache. Wouldn't this put an end to self-contained modules? I wrote in a latter mail (is this the same thread? Sorry, I use this only through Thunderbird and get confused sometimes) how I see need for explicit module dependencies and a system that can automatically download required modules from the forge. I can see this supplementing your idea of constraints nicely, but without it, downloading modules could quickly become a nightmare for users. Cheers, Felix -- 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] Multiple Service definitions of the same type
Hi, On 01/24/2012 11:50 PM, Bryan Beaudreault wrote: I have a special init.d script that can handle this, but want to define the service multiple times in a puppet class. I assume your new initscript declares a different Provides: tag than the stock memcached initscript, yes? Whatever this tag is, that's what your service resource should be named, and (as Ramin pointed out correctly), you should not try and alias this service to memcached (even though that's what you're ultimately starting). If your new script does indeed provide memcached as well, that is a problem in and of itself and needs fixing. HTH, Felix -- 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: Cross-module dependencies
Hello, On Fri, Jan 27, 2012 at 15:20, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: how I see need for explicit module dependencies and a system that can automatically download required modules from the forge. I can see this supplementing your idea of constraints nicely, but without it, downloading modules could quickly become a nightmare for users. There's something else we need to think about here. Some modules have a soft/conditional requirement for other modules. What I mean is that if you don't use certain parts of a module, you don't need the module that that part of the code refers to. the only decent way I can come up with to solve that is to use what for instance in C is done with #IFDEF. That way the module could just ignore modules that it doesn't _really_ require. I for instance have modules that allow you to use different backends for monitoring or backups. If requirements were done automatically based on the whole module, it would need a myriad of other modules, only one of which is ever used. cheers, -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- 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: Cross-module dependencies
On 26/01/12 17:48, jcbollinger wrote:
In particular, it is useful to recognize that dependencies are not just on a
particular resource generally -- rather, they are on a particular resource
having certain specific properties.
Yes.
Also: currently in Puppet one cannot say anything about a resource without a
declaration that you will manage it. (Unless perhaps that state happens to be
encapsulated by a Fact, which typically isn't and in many cases couldn't
feasibly be - like the case of file attributes.)
Therefore many dependencies are created only because of a need to check some
state of a resource - which one may not want or need to manage.
Consider, then, a new metaresource type, Constraint. The purpose of the
Constraint resource type would be to allow multiple unrelated classes to
collaborate on defining the properties of a single resource, and it would do
so by allowing classes to limit the values that chosen resource properties
may have.
At compilation time, Puppet would collect and combine all the constraints on
any particular resource, and use the results to set unspecified property
values and validate specified ones. Usage might look something like this:
constraint { 'webserver-httpd_package-present':
resource = Package['httpd'],
property = 'ensure',
forbidden_value = [ 'absent', 'purged' ],
# also available: allowed_value
# maybe: default_value
}
Not only would this nicely meet the needs of different modules to express
their requirements on shared resources, it would also make it much easier to
recognize resource conflicts. If Puppet automatically generated empty
resource definitions to constrain when it discovered constraints on
otherwise-undefined resources, then that would also overcome the problem of
deciding where to define particular resources.
I can imagine many -- perhaps most -- resource definitions being replaced or
supplemented by constraint declarations.
Here's a slightly different angle.
(Note, I'll use capitalisation distinguish between the resources that exist
outside Puppet, and the Resource instances inside, which model them.)
I think there *is* a case to be made that Puppet needs a new kind of Resource
declaration. One which promises never to change the state of anything.
Immutability is, I think, the key to allowing multiple declarations of this sort
co-exist. Resources currently have to uniquely own a resource so that they can
safely change it. As I said, one doesn't always need or want that ownership: we
know the kind of baggage it carries.
Ideally we'd be able to separate out the aspects of a Resource which merely
assert what *should* be the case (ensure = present etc.) from those bits which
would then change the state of the resource if it deviates.
For the sake of discussion I'll call that former kind of declaration an
Assertion.
To briefly address the points from earlier email: Nan asked how would one
address merging, with respect to the following aspects of a Resource?
a) unifying before/requires attributes
b) unifying if/then/else constructs
c) auditing changes back to their source
d) unifying hash/array attributes
Well, when using Resources, yes, these make them very hard to unify in general.
However - although this needs more thought - if we could invent some way to
declare mere Assertions, they might do instead of Resources for many cases, and
it might be possible to unify them more simply, because:
a) Problems related to ordering mostly disappear,
...since nothing is being changed. (Of course, external things which might
change things could be a problem.)
b) If/then/else clauses can still make sense within definitions of custom
Assertions,
...if they can compose only other Assertions, and the conditions don't change.
c) Auditing is not a problem: since nothing is changed, there is nothing to
audit.
d) Hash/array attribute values would need to be resolved on a case-by-case
basis,
...depending on the semantics. When hash and arrays are semantically
representing are sets, this should be a straightforward and or or operation.
When the order matters, like a search path, or there is no obvious way to unify
two attributes, then this is an unresolvable contradiction and should generate
an error. There may be cases in between.
Possibly this doesn't fit all the use-cases which run into cross-module
dependency problems, but might significantly reduce the need to create the
dependencies in the first place.
Anyway, I need to get back to work, I'll try to say more in a later email.
Cheers,
N
--
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: Cross-module dependencies
Hi,
On 01/27/2012 02:52 PM, Walter Heck wrote:
There's something else we need to think about here. Some modules have
a soft/conditional requirement for other modules. What I mean is that
if you don't use certain parts of a module, you don't need the module
that that part of the code refers to. the only decent way I can come
up with to solve that is to use what for instance in C is done with
#IFDEF. That way the module could just ignore modules that it doesn't
_really_ require.
thanks for pointing this out, but it has been covered (I think) in
another thread already:
On 01/19/2012 09:17 PM, Nick Fagerlund wrote:
So, you can conditionally declare the rule if the defined type is
available to the autoloader, and otherwise you don't attempt to manage
the firewall and expect that the user has read the documentation and
will make a hole for the service themselves.
if defined(firewall::iptables::rule) {
firewall::iptables::rule {'mysql_server':
...etc. etc.
}
}
See? It's just a way to peek around at what the user has installed.
Thanks again to Nick for this quote, it keeps proving useful ;-)
Cheers,
Felix
--
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: Managing SSH host private keys
On Jan 26, 1:42 pm, Christopher Wood christopher_w...@pobox.com wrote: On Thu, Jan 26, 2012 at 06:32:49PM +, Dan White wrote: I am relatively new to both Puppet and ssh-keys, but is it possible for the PuppetMaster to generate all the keys rather that each client creating their own ? This might be one of the places where erb (templates) being evaluated on the puppetmaster will help. I'm just speculating, but there's no technological reason why the puppetmaster shouldn't use erb/ruby to fork ssh-keygen and store the result in some local directory. The puppet template can either create a private key, or copy in the results of a previous ssh-keygen run. I don't see technical obstacles, only security obstacles. You may not want all your ssh private keys stored in one place, for instance. Agreed, My first thought is to be sure a backup of the private keys is kept current and separate - and possibly in multiple locations. Any other security considerations one should consider ? In my current workplace, ssh keys are used for remote machine logins and the individual user is responsible for maintaining their own private key. I am not completely happy with this arrangement, and I am looking for information to use to make some intelligent suggestions for change. -- 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: Cross-module dependencies
On Jan 27, 7:20 am, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Hi John, thanks for coming up with such elaborate ideas, your input to this group adds a lot of meat to many discussions. I can agree with a lot of what you wrote, barring the following remarks: On 01/26/2012 06:00 PM, jcbollinger wrote: Modules provide definitions of resources that they own. For the most part, those definitions should be virtual to avoid unnecessary inter- module coupling, but some resources are reasonable to define concretely. Jeff has made a strong point against using virtual resources in modules at all, causing me to shift my own views as well. If I understand him correctly, one of the chief problems is the high probability of accidental collection/realisation of such resources by the end user's manifest. The core problem to solve is that multiple modules may depend on the same resources, but each resource can be defined only once. If modules' resource requirements were invariant then I could be satisfied with documenting them and requiring the user to provide them concretely; indeed, that's not very far from what I just proposed. On the contrary, however, whether a particular resource is needed by some module may depend on which of that module's classes are used, and on which parameters and external data are supplied. This approach therefore has its own inherent problem for users: to avoid declaring unneeded resources. Given a choice between the problems of avoiding declaring unneeded resources and of avoiding collecting unwanted resources, I would choose the latter. It is easier to deal with, and failure to completely solve it is no more costly than failure to solve the alternative problem. On 01/26/2012 06:48 PM, jcbollinger wrote: I can imagine many -- perhaps most -- resource definitions being replaced or supplemented by constraint declarations. The model is intriguing, but gives me another usability headache. From a usability perspective, I think this is a far better proposal than anything else on the table: (+) It enables modules to declare their requirements more precisely, reducing the risk of modules compiling and applying correctly, but nevertheless failing to achieve the desired configuration. Constraints are the only proposal currently on the table that provide that. (+) A key aspect is that it allows Puppet to pinpoint and diagnose conflicts at compilation time. (+) Furthermore, it allows each module to express *only* its requirements, ignoring properties that it doesn't care about (though other modules might care about them). In fact, it rewards modules for doing so by making them more interoperable. (+) It does not rely on virtual resources (though it is compatible with them), so it does not impose any risk of accidental resource collection. (+) It could be implemented in a manner that forestalls inter-module parse order dependencies. The main cost I see is: (-) It creates a new distinction between resource properties that are explicitly specified in resource definitions and those that are not. For this reason (at least), such a feature could not be introduced until Telly at the earliest. That cost is incurred, however, only in manifest sets that use Constraints, and then only with respect to resources that are targeted by Constraints. It is anyway not a usability issue, but rather an upgrade / conversion / compatibility issue. Wouldn't this put an end to self-contained modules? No. What makes you think it would? I think it allows modules to be *more* self-contained than they currently are. I wrote in a latter mail (is this the same thread? Sorry, I use this only through Thunderbird and get confused sometimes) how I see need for explicit module dependencies and a system that can automatically download required modules from the forge. I can see this supplementing your idea of constraints nicely, but without it, downloading modules could quickly become a nightmare for users. I have considered that possibility, essentially a package management system for Puppet modules. Although such a thing could undoubtedly be implemented, I don't think it would be very suitable for addressing the inter-module dependency problem. Package management systems such as yum and apt rely on the fact that software dependency graphs are more or less trees, but I don't think module dependency graphs tend to be anywhere near as treelike. I suppose module repository managers could enforce tree-shaped dependency graphs, but that imposes the tool's requirements on the problem space instead of relying on a tool that suits well in the first place. I do not mean to say that a tool that automatically downloaded and installed modules from the Forge would be useless -- far from it. I just don't think that it would adequately address the inter-module dependency issue, and therefore I would recommend that such a tool not even try to do so. It solves an altogether
[Puppet Users] Re: How do *you* handle yumrepo dependency chains?
On Jan 26, 8:56 am, jimbob palmer jimbobpal...@gmail.com wrote: Say you have a RHEL6 environment. You have some packages you want installed, these rely on a yumrepo. That yumrepo relies on an rpm-gpg key being installed. Now you get some RHEL5 boxes to add to the network. Your yumrepo RHEL6.2 with a dependency on the RHEL6 signing key now causes a problem: all of the rpms you need are the same, but those rpms rely on the RHEL6.2 yumrepo which is wrong, and that relies on the RHEL6 signing key which is wrong too. What approach do you use? Option 1: define separate Yumrepos for the RHEL5 repositories, with appropriate dependencies, and define Packages' Yumrepo dependencies conditionally based on OS release. Option 2: define the Yumrepo properties conditionally based on OS release. Which of these best suits may depend on what work you have already done. Surely you are not declaring RHEL6 Yumrepos for your RHEL5 boxes (or else fix that!), so just make your Packages 'require' the Yumrepos that you are actually declaring. That's the essence of both options. 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] [Dashboard] Debian squeeze rack 1.4.1
Hi everyone, I am trying to setup puppet-dashboard when trying to use the rake RAILS_ENV=production db:migrate I have the following error: # rake RAILS_ENV=production db:migrate NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. rake aborted! Could not find rack (~ 1.1.0) amongst [actionmailer-3.2.0, actionpack-3.2.0, activemodel-3.0.10, activerecord-3.0.10, activeresource-3.2.0, activesupport-3.0.10, arel-3.0.0, arel-2.0.10, builder-3.0.0, builder-2.1.2, bundler-1.0.21, daemon_controller-0.2.6, erubis-2.7.0, facter-1.6.5, facter-1.6.4, fastthread-1.0.7, hike-1.2.1, i18n-0.6.0, i18n-0.5.0, journey-1.0.0, json-1.6.5, mail-2.4.1, mime-types-1.17.2, multi_json-1.0.4, mysql-2.8.1, mysql2-0.3.11, passenger-3.0.11,
[Puppet Users] Re: Compiled catalog arount 70s
On Jan 27, 4:02 am, Antidot SAS antidot...@gmail.com wrote: Hi everyone, I am using puppet 2.7.9 and ruby 1.8.7 on debian box. I don't a lot of modules right now: just one module that create user + dotfile + ssh key and compiled catalog takes around 70s do I have to worry is that big. That's pretty excessive. My manifests are considerably more complex than you describe, and my compilation times average around 1s. Exact timing also depends on the hardware, of course, but something is wrong for you if it takes 70s to compile a simple catalog. We could be more helpful if you gave us a manifest set that exhibits the problem. Does the compiled time scale with the module number? Do I have to make sure I don't cross a certain limit? Compilation time scales with the number and complexity of the manifests to compile. That is correlated to the number of modules used (not the number installed) inasmuch as using more modules implies compiling more manifests. The actual number of manifests compiled depends on the details of the modules involved and their manner of use, however. As for limits, the more work your master needs to do to compile each node's catalog, the fewer nodes it can serve. In the extreme that compilation time approached or exceeded the delay between agent runs, effectively the master could serve only a single node. 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] ssh_authorized_key in 2.7.10 keeps looping when options are set
On Fri, Jan 27, 2012 at 10:27 AM, rvlinden rene.vanderlinde...@gmail.com wrote: Hi all, I just upgraded a client with puppet 2.7.9 to 2.7.10 and now the authorized_keys started to loop notice: /Stage[main]/Authorizedkey::UserX/ Authorizedkey::Manage[userx_dss_domainx_test]/ Ssh_authorized_key[userx_dss_domainx_test]/options: options changed 'no-port-forwarding,no-agent-forwarding,no-X11-forwarding' to 'no-port- forwarding,no-agent-forwarding,no-X11-forwarding' It says it changed .ssh/authorized_keys, but when I compare the current authorized_keys in the user's homedir with the one in the filebucket, they are identical. The only difference is the date/ timestamp diff # HEADER: This file was autogenerated at Fri Jan 27 16:10:31 +0100 2012 --- # HEADER: This file was autogenerated at Fri Jan 27 16:12:58 +0100 2012 It only loops on authorized keys with options, which are configured as an array like this options = [ 'no-port-forwarding', 'no-agent-forwarding', 'no-X11-forwarding', ] Perhaps a variation of this issue: http://projects.puppetlabs.com/issues/12197 There's an ongoing thread, and check if you have Ruby 1.8.7. 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: Cross-module dependencies
Hi, On 01/27/2012 04:22 PM, jcbollinger wrote: From a usability perspective, I think this is a far better proposal than anything else on the table: I've thought of another plus. Even though the design proposal adds to the DSL (and complexity is generally to be avoided), it does so in a manner that will not make it necessary for novices (or any end user) to deal with the particular featureset, but instead limits its target audience to developers of public modules. Wouldn't this put an end to self-contained modules? No. What makes you think it would? I think it allows modules to be *more* self-contained than they currently are. I was thinking along the lines of currently modules will just install the packages they need, for instance. But you're right of course - currently modules can break each other because of this, so a way for the compiler to clearly pinpoint reasons and locations of mismatches would indeed be superior. I do not mean to say that a tool that automatically downloaded and installed modules from the Forge would be useless -- far from it. I just don't think that it would adequately address the inter-module dependency issue, and therefore I would recommend that such a tool not even try to do so. It solves an altogether different problem. Again, I'm inclined to concur. The issue at hand is to stop modules from breaking each other horribly. Once that's off the table, a module management system is a whole new issue in and of itself. Cheers, Felix -- 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: ssh_authorized_key in 2.7.10 keeps looping when options are set
Thanks I run puppet on RHEL5 with Ruby 1.8.7 On Jan 27, 4:56 pm, Nan Liu n...@puppetlabs.com wrote: On Fri, Jan 27, 2012 at 10:27 AM, rvlinden rene.vanderlinde...@gmail.com wrote: Hi all, I just upgraded a client with puppet 2.7.9 to 2.7.10 and now the authorized_keys started to loop notice: /Stage[main]/Authorizedkey::UserX/ Authorizedkey::Manage[userx_dss_domainx_test]/ Ssh_authorized_key[userx_dss_domainx_test]/options: options changed 'no-port-forwarding,no-agent-forwarding,no-X11-forwarding' to 'no-port- forwarding,no-agent-forwarding,no-X11-forwarding' It says it changed .ssh/authorized_keys, but when I compare the current authorized_keys in the user's homedir with the one in the filebucket, they are identical. The only difference is the date/ timestamp diff # HEADER: This file was autogenerated at Fri Jan 27 16:10:31 +0100 2012 --- # HEADER: This file was autogenerated at Fri Jan 27 16:12:58 +0100 2012 It only loops on authorized keys with options, which are configured as an array like this options = [ 'no-port-forwarding', 'no-agent-forwarding', 'no-X11-forwarding', ] Perhaps a variation of this issue:http://projects.puppetlabs.com/issues/12197 There's an ongoing thread, and check if you have Ruby 1.8.7. Nan- Hide quoted text - - Show quoted text - -- 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: Compiled catalog arount 70s
Hey thx for the answer... the puppetmaster is an old Poweredge SC1425 with 2 Go of RAM and 4 CPU (Intel Xeon 2.8Ghz) Regarding the catalog it is playing a lot with hash tables... Trying to figure out a way to show it to you... Attachment could be a way? On Fri, Jan 27, 2012 at 4:55 PM, jcbollinger john.bollin...@stjude.orgwrote: On Jan 27, 4:02 am, Antidot SAS antidot...@gmail.com wrote: Hi everyone, I am using puppet 2.7.9 and ruby 1.8.7 on debian box. I don't a lot of modules right now: just one module that create user + dotfile + ssh key and compiled catalog takes around 70s do I have to worry is that big. That's pretty excessive. My manifests are considerably more complex than you describe, and my compilation times average around 1s. Exact timing also depends on the hardware, of course, but something is wrong for you if it takes 70s to compile a simple catalog. We could be more helpful if you gave us a manifest set that exhibits the problem. Does the compiled time scale with the module number? Do I have to make sure I don't cross a certain limit? Compilation time scales with the number and complexity of the manifests to compile. That is correlated to the number of modules used (not the number installed) inasmuch as using more modules implies compiling more manifests. The actual number of manifests compiled depends on the details of the modules involved and their manner of use, however. As for limits, the more work your master needs to do to compile each node's catalog, the fewer nodes it can serve. In the extreme that compilation time approached or exceeded the delay between agent runs, effectively the master could serve only a single node. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Compiled catalog arount 70s
On Fri, 2012-01-27 at 11:02 +0100, Antidot SAS wrote: Hi everyone, I am using puppet 2.7.9 and ruby 1.8.7 on debian box. I don't a lot of modules right now: just one module that create user + dotfile + ssh key and compiled catalog takes around 70s do I have to worry is that big. 70s is very high. My biggest node has around 2000 resources, and it takes around 12s to compile (including storeconfigs) on a 4 year old Dell 2950 (one 4C 1.18GHz processor, 4GiB RAM). Compilation time depends on two things: * the complexity (in number of classes or resources) of your manifests * the number of concurrent nodes asking for catalog (the more node asking for catalogs, the more load on your server and processes start to fight for CPU/RAM). Also, if you have storeconfigs enabled, this can take quite some time. In which case I suggest to run with thin_storeconfigs instead of the full one if you can. You might also want to check that your server is not swapping. Does the compiled time scale with the module number? Do I have to make sure I don't cross a certain limit? -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- 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: Compiled catalog arount 70s
70s sounds does sound a bit high for managing only three resources, but more info is required before I can really answer your question. How did you install Puppet? (OS packages, gem?) What OS are you running, and can you provide some info about the Hardware? Also, if you have a sample of the manifest that you are using that would be great as well. On Jan 27, 5:02 am, Antidot SAS antidot...@gmail.com wrote: Hi everyone, I am using puppet 2.7.9 and ruby 1.8.7 on debian box. I don't a lot of modules right now: just one module that create user + dotfile + ssh key and compiled catalog takes around 70s do I have to worry is that big. Does the compiled time scale with the module number? Do I have to make sure I don't cross a certain limit? Regards, JM -- 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] SSL Errors - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B
Hello, I'm new to puppet and am getting a puppet server setup with puppet dashboard. I have the puppet server and puppet dashboard (Apache/Passenger) setup and working well with 60+ test nodes working as expected. Only problem is that I have this one error in the logs which I can't figure out. Jan 26 17:09:41 ppt01 puppet-agent[27357]: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client Jan 26 17:09:41 ppt01 puppet-agent[27357]: Using cached catalog Jan 26 17:09:42 ppt01 puppet-agent[27357]: (/Stage[main]/Puppet/File[run_puppet.sh]) Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client Could not retrieve file metadata for puppet:///modules/puppet/run_puppet.sh: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client at /etc/puppet/modules/puppet/manifests/init.pp:67 Jan 26 17:09:42 ppt01 puppet-agent[27357]: (/Stage[main]/Puppet/Cron[puppet]) Dependency File[run_puppet.sh] has failures: true Jan 26 17:09:42 ppt01 puppet-agent[27357]: (/Stage[main]/Puppet/Cron[puppet]) Skipping because of failed dependencies Jan 26 17:09:42 ppt01 puppet-agent[27357]: Finished catalog run in 0.21 seconds Jan 26 17:09:42 ppt01 puppet-agent[27357]: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client These errors are from the puppet agent that is running on the puppet-master server. The odd thing is if I run it manually everything works as it should. I also have a cron job that runs it every 30 minutes and this works fine as well. I have no idea how the puppet agent is getting called during this failed run. It happens reliably every 30 minutes but outside of the time that my cron job runs... Does anyone have any idea what might be calling this failed run? Something with the dashboard I'm guessing but I'm unable to find anything. Next odd thing is that this failed run also doesn't appear to be affecting anything. All the Dashboard (and puppet master) functionality is working as it should, including reporting, filebucketing and inventory. All clients are getting their catalogs, etc... so I'm really not sure where this is originating from. I should note that I did change the hostname the puppet server is using but updated every (I think) to reflect the new hostname, including regenerating the server and client certs. I've found this page: http://docs.puppetlabs.com/pe/2.0/maint_common_config_errors.html#do-agents-trust-the-masters-certificate which covers these errors but they don't seem to be my issue. It's obviously not a time issue considering the agent that is complaining in on the master. I've `puppet cert clean`-ed, re-re-created and re-signed the client certs against the new master certs and the puppet agent runs are working from my cron calls and when run manually. Any help in determining where this is getting called from and how I can clear it up would be greatly appreciated. Here is my puppet.conf on my master. I'd be happy to provide any other info that my be helpful. [agent] server = host.pvt.domain.com report = true [master] ssldir = $vardir/ssl certname = host.pvt.domain.com # For the Inventory service facts_terminus = inventory_active_record dbadapter = mysql dbname = puppet_inventory dbuser = puppet dbpassword = super-secret dbserver = localhost dbsocket = /var/lib/mysql/mysql.sock # For reports reports = store, http reporturl = http://host.pvt.domain.com/reports/upload # For puppet dashboards external node classification. node_terminus = exec external_nodes = /usr/bin/env PUPPET_DASHBOARD_URL=http://puppet:80 /usr/share/puppet-dashboard/bin/external_node Thank you, -- Romeo -- 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] ssh::auth sign of life?
Hi, First I would like to start of with a quote from http://projects.puppetlabs.com/projects/puppet/wiki/Module_Ssh_Auth_Patterns. ssh::auth is currently in an unstable release. Please test it, and report bugs and feature requests on the Puppet users mailing list. Based on the results of people’s testing, the interface may change for the first stable release. Last update was 2010-03-29. Is it still unstable? Has anyone used this ssh::auth before? Has anyone forked it and maintains it? I'm looking for a module to maintain some users and their ssh keys and would like some feedback from anyone that has any experience in something like this. Regards, Elias -- 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] yum.puppetlabs.com and downloads.puppetlabs.com unreachable
Since several weeks, both yum.puppetlabs.com and downloads.puppetlabs.com are unreachable from some connections. This is showing every time I check for updates in the repository. It seems that there is a problem in routing. See: traceroute to yum.puppetlabs.com (96.126.116.126), 30 hops max, 40 byte packets 1 … 2 … 3 vlan130.newxr2.nik-asd.internl.net (217.149.196.89) 2.124 ms 2.251 ms 2.709 ms 4 vlan51.newxr1.nik-asd.internl.net (217.149.207.201) 2.963 ms 2.886 ms 2.932 ms 5 bbr01.eq01.ams01.networklayer.com (195.69.146.82) 2.848 ms 2.865 ms 3.155 ms 6 ae7.bbr02.eq01.ams02.networklayer.com (50.97.18.213) 3.447 ms 3.368 ms 3.415 ms 7 ae0.bbr02.tg01.lon01.networklayer.com (50.97.18.210) 16.768 ms 11.892 ms 11.778 ms 8 ae7.bbr01.tg01.lon01.networklayer.com (50.97.18.206) 38.213 ms 38.338 ms 35.312 ms 9 ae1.bbr02.tl01.nyc01.networklayer.com (50.97.18.204) 74.553 ms 75.003 ms 74.937 ms 10 ae1.bbr01.eq01.chi01.networklayer.com (173.192.18.132) 96.712 ms 96.987 ms 97.576 ms 11 ae20.bbr01.eq01.dal03.networklayer.com (173.192.18.136) 115.286 ms 114.407 ms 114.534 ms 12 po31.dsr02.dllstx3.networklayer.com (173.192.18.227) 144.169 ms 140.364 ms 140.263 ms 13 * * * 14 po2.car01.dllstx2.networklayer.com (70.87.254.78) 115.204 ms 114.533 ms 114.426 ms 15 5a.7.1243.static.theplanet.com (67.18.7.90) 114.740 ms 116.290 ms 116.175 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 etc… When I traceroute to puppetlabs.com, all is well: traceroute to puppetlabs.com (96.126.112.51), 30 hops max, 40 byte packets 1 … 2 … 3 vlan130.newxr2.nik-asd.internl.net (217.149.196.89) 2.551 ms 2.659 ms 2.095 ms 4 vlan51.newxr1.nik-asd.internl.net (217.149.207.201) 1.338 ms 2.002 ms 1.878 ms 5 bbr01.eq01.ams01.networklayer.com (195.69.146.82) 43.903 ms 44.072 ms 43.848 ms 6 ae7.bbr02.eq01.ams02.networklayer.com (50.97.18.213) 1.521 ms 1.859 ms 1.598 ms 7 ae0.bbr02.tg01.lon01.networklayer.com (50.97.18.210) 7.397 ms 7.434 ms 7.423 ms 8 ae7.bbr01.tg01.lon01.networklayer.com (50.97.18.206) 8.290 ms 8.152 ms 8.367 ms 9 ae1.bbr02.tl01.nyc01.networklayer.com (50.97.18.204) 75.874 ms 75.963 ms 76.013 ms 10 * * * 11 ae20.bbr01.eq01.dal03.networklayer.com (173.192.18.136) 119.603 ms 121.916 ms 121.599 ms 12 po31.dsr01.dllstx3.networklayer.com (173.192.18.225) 121.406 ms 120.453 ms 120.361 ms 13 te3-2.dsr01.dllstx2.networklayer.com (70.87.253.130) 120.158 ms 118.674 ms 118.645 ms 14 po1.car01.dllstx2.networklayer.com (70.87.254.74) 118.616 ms 118.558 ms 118.822 ms 15 5a.7.1243.static.theplanet.com (67.18.7.90) 122.036 ms 119.985 ms 119.083 ms From some other connections I can reach yum,puppetlabs.com without a problem. Anyone else seeing this as well? Is there a solution? -- 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] Puppet agents stop reporting after master runs out of disk space...
I am experiencing a curious event, and wondering if others have seen this... As well, I have a question related to it. Today, I noticed my puppet summary report from Foreman this morning, that 60 of my 160 hosts all stopped reporting at nearly the exact same time, and have not since restarted. Investigating, it appears that my puppetmaster temporarily ran out of disk space on the /var volume, probably in part do to logging. I have log rollers running, which eventually freed up some disk space, but the 60 hosts, have not resumed reporting. If I dig into the logs on one of the failing agents, there are no messages from puppet, past 4am (here is a snippet of my logs): Jan 27 02:44:25 kmallory3 puppet-agent[15340]: Using cached catalog Jan 27 02:44:25 kmallory3 puppet-agent[15340]: Could not retrieve catalog; skipping run Jan 27 03:14:30 kmallory3 puppet-agent[15340]: Could not retrieve catalog from remote server: Error 400 on SERVER: No space left on device - /var/lib/puppet/yaml/facts/kmallory3.xxx.xxx.xxx.yaml Jan 27 03:14:30 kmallory3 puppet-agent[15340]: Using cached catalog Jan 27 03:14:30 kmallory3 puppet-agent[15340]: Could not retrieve catalog; skipping run Jan 27 03:47:30 kmallory3 puppet-agent[15340]: Could not retrieve plugin: execution expired Jan 27 04:01:02 kmallory3 puppet-agent[15340]: Could not retrieve catalog from remote server: execution expired Jan 27 04:01:02 kmallory3 puppet-agent[15340]: Using cached catalog Jan 27 04:01:02 kmallory3 puppet-agent[15340]: Could not retrieve catalog; skipping run Forcing a run of puppet, I get the following message: kmallory3:/var/log# puppetd --onetime --test notice: Ignoring --listen on onetime run notice: Run of Puppet configuration client already in progress; skipping After stopping and restarting the puppet service, the agent started running properly. It appears that the failure from the server has caused the agent to hang, from which it was not able to recover gracefully. Has anyone experienced this before? We are running 2.6.1 on the large majority of our hosts, including this one. Many failed, but 2/3rds keep running properly. Now, on to my question.. Anyone got some bright ideas for how I could force Puppet to restart itself on a 60 machines, when Puppet isn't running?? I'm not really excited by the prospect of logging into 60 machines, and running a sudo command... sigh. --Kyle -- 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: Cross-module dependencies
On Jan 27, 8:01 am, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Hi, On 01/27/2012 02:52 PM, Walter Heck wrote: There's something else we need to think about here. Some modules have a soft/conditional requirement for other modules. What I mean is that if you don't use certain parts of a module, you don't need the module that that part of the code refers to. the only decent way I can come up with to solve that is to use what for instance in C is done with #IFDEF. That way the module could just ignore modules that it doesn't _really_ require. thanks for pointing this out, but it has been covered (I think) in another thread already: On 01/19/2012 09:17 PM, Nick Fagerlund wrote: [...] And Nick's approach seems good and useful, but I don't think it addresses Walter's concern. Walter observes that modules' runtime inter-module dependencies can depend on how they are used, and he argues, I think, that that complicates the problem of managing such dependencies via a package management system. For example, if module X depends on module Y only for feature X::ySupport, and I intend never to use X::ySupport, then I might like to avoid installing module Y. If I furthermore want to use module Y2 that is incompatible with module Y, then I might *need* to avoid installing Y. There are ways to handle problems such as those, but it all creates a lot of overhead to make everything work together properly in such a scheme. John A hollow voice says Plugh. -- 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: Compiled catalog arount 70s
Here are the info you wanted: OS: Debian squeeze Puppet: installed from gem version 2.7.9 As I sayed the hardware is an old Poweredge SC1425 with 4 Xeon 2,8 Ghz with 2 Go of Memory Apparently the code is preety ugly since the compiled time is big, I have just share the code: https://github.com/jmauro/puppet-user The compilation time increased when I want to create about 50 employe for instance in the file admin/params.pp Let me know if you see something odd or If I misunderstand a concept. Regards, JM On Fri, Jan 27, 2012 at 1:26 PM, Kelsey Hightower kel...@puppetlabs.comwrote: 70s sounds does sound a bit high for managing only three resources, but more info is required before I can really answer your question. How did you install Puppet? (OS packages, gem?) What OS are you running, and can you provide some info about the Hardware? Also, if you have a sample of the manifest that you are using that would be great as well. On Jan 27, 5:02 am, Antidot SAS antidot...@gmail.com wrote: Hi everyone, I am using puppet 2.7.9 and ruby 1.8.7 on debian box. I don't a lot of modules right now: just one module that create user + dotfile + ssh key and compiled catalog takes around 70s do I have to worry is that big. Does the compiled time scale with the module number? Do I have to make sure I don't cross a certain limit? Regards, JM -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] finally have puppet/passenger/dashboard working... new problem
What the heck does this mean? err: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method `fact_merge' for nil:NilClass warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run Only seems to be happening on one host in particular... -- Peter L. Berghold Owner, Shark River Technical Solutions LLC -- 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: Cross-module dependencies
On Jan 27, 7:58 am, Nick oinksoc...@letterboxes.org wrote: On 26/01/12 17:48, jcbollinger wrote: In particular, it is useful to recognize that dependencies are not just on a particular resource generally -- rather, they are on a particular resource having certain specific properties. Yes. Also: currently in Puppet one cannot say anything about a resource without a declaration that you will manage it. (Unless perhaps that state happens to be encapsulated by a Fact, which typically isn't and in many cases couldn't feasibly be - like the case of file attributes.) Of course, this is a question of scale and foreknowledge. One can easily create a custom fact expressing any or all of the attributes of a specific file. I think one could even do it for all of the files in a directory, or even for an entire directory tree. Before too long, however, that's going to become quite slow, and it would be difficult to use on the Puppet side. I can't think of a persistent node state detail that couldn't be expressed via a custom fact, but if you need many such details, or if you can't be sure in advance which you will need, then you do have a problem. Therefore many dependencies are created only because of a need to check some state of a resource - which one may not want or need to manage. It sounds like you want to perform conditional logic on the agent. I am not at all comfortable with that idea, though perhaps I could become more so. It entails a much more fundamental change to Puppet than anything else we have been discussing. Or did you have something different in mind? Here's a slightly different angle. [...] Ideally we'd be able to separate out the aspects of a Resource which merely assert what *should* be the case (ensure = present etc.) from those bits which would then change the state of the resource if it deviates. For the sake of discussion I'll call that former kind of declaration an Assertion. [...] Possibly this doesn't fit all the use-cases which run into cross-module dependency problems, but might significantly reduce the need to create the dependencies in the first place. I could see implementing a version of your Assertion idea as a check- only Constraint, but I don't think there is yet an infrastructure to support that part. However, I don't see at all how the Assertion idea fits into the cross-module dependency picture. Perhaps this is because I don't see the purpose of declaring resources that you do not intend to manage. When I consider cross-module dependencies, I think the usual case is that a module *does* want ensure that particular resource properties are managed, but it may not care about other properties, and it cares about who owns Resources only insofar as someone has to own them and it affects who can manage them. I can imagine wanting to _assert_ Resource properties only as a workaround for not being able actually to manage them. Are there other reasons to want such a thing? Anyway, I need to get back to work, I'll try to say more in a later email. That would help me to determine what I think about the idea. As it is, I suspect I don't quite understand what you are hoping to accomplish with it. 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] [Dashboard] Debian squeeze rack 1.4.1
On Fri, Jan 27, 2012 at 7:49 AM, Antidot SAS antidot...@gmail.com wrote: Hi everyone, I am trying to setup puppet-dashboard when trying to use the rake RAILS_ENV=production db:migrate I have the following error: # rake RAILS_ENV=production db:migrate NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. rake aborted! Could not find rack (~ 1.1.0) amongst [actionmailer-3.2.0, actionpack-3.2.0, activemodel-3.0.10, activerecord-3.0.10, activeresource-3.2.0, activesupport-3.0.10, arel-3.0.0, arel-2.0.10, builder-3.0.0, builder-2.1.2, bundler-1.0.21, daemon_controller-0.2.6, erubis-2.7.0, facter-1.6.5, facter-1.6.4,
Re: [Puppet Users] yum.puppetlabs.com and downloads.puppetlabs.com unreachable
On Fri, Jan 27, 2012 at 2:59 AM, Erwin erwin.boga...@gmail.com wrote: Since several weeks, both yum.puppetlabs.com and downloads.puppetlabs.com are unreachable from some connections. This is showing every time I check for updates in the repository. It seems that there is a problem in routing. See: traceroute to yum.puppetlabs.com (96.126.116.126), 30 hops max, 40 byte packets 1 … 2 … 3 vlan130.newxr2.nik-asd.internl.net (217.149.196.89) 2.124 ms 2.251 ms 2.709 ms 4 vlan51.newxr1.nik-asd.internl.net (217.149.207.201) 2.963 ms 2.886 ms 2.932 ms 5 bbr01.eq01.ams01.networklayer.com (195.69.146.82) 2.848 ms 2.865 ms 3.155 ms 6 ae7.bbr02.eq01.ams02.networklayer.com (50.97.18.213) 3.447 ms 3.368 ms 3.415 ms 7 ae0.bbr02.tg01.lon01.networklayer.com (50.97.18.210) 16.768 ms 11.892 ms 11.778 ms 8 ae7.bbr01.tg01.lon01.networklayer.com (50.97.18.206) 38.213 ms 38.338 ms 35.312 ms 9 ae1.bbr02.tl01.nyc01.networklayer.com (50.97.18.204) 74.553 ms 75.003 ms 74.937 ms 10 ae1.bbr01.eq01.chi01.networklayer.com (173.192.18.132) 96.712 ms 96.987 ms 97.576 ms 11 ae20.bbr01.eq01.dal03.networklayer.com (173.192.18.136) 115.286 ms 114.407 ms 114.534 ms 12 po31.dsr02.dllstx3.networklayer.com (173.192.18.227) 144.169 ms 140.364 ms 140.263 ms 13 * * * 14 po2.car01.dllstx2.networklayer.com (70.87.254.78) 115.204 ms 114.533 ms 114.426 ms 15 5a.7.1243.static.theplanet.com (67.18.7.90) 114.740 ms 116.290 ms 116.175 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 etc… When I traceroute to puppetlabs.com, all is well: traceroute to puppetlabs.com (96.126.112.51), 30 hops max, 40 byte packets 1 … 2 … 3 vlan130.newxr2.nik-asd.internl.net (217.149.196.89) 2.551 ms 2.659 ms 2.095 ms 4 vlan51.newxr1.nik-asd.internl.net (217.149.207.201) 1.338 ms 2.002 ms 1.878 ms 5 bbr01.eq01.ams01.networklayer.com (195.69.146.82) 43.903 ms 44.072 ms 43.848 ms 6 ae7.bbr02.eq01.ams02.networklayer.com (50.97.18.213) 1.521 ms 1.859 ms 1.598 ms 7 ae0.bbr02.tg01.lon01.networklayer.com (50.97.18.210) 7.397 ms 7.434 ms 7.423 ms 8 ae7.bbr01.tg01.lon01.networklayer.com (50.97.18.206) 8.290 ms 8.152 ms 8.367 ms 9 ae1.bbr02.tl01.nyc01.networklayer.com (50.97.18.204) 75.874 ms 75.963 ms 76.013 ms 10 * * * 11 ae20.bbr01.eq01.dal03.networklayer.com (173.192.18.136) 119.603 ms 121.916 ms 121.599 ms 12 po31.dsr01.dllstx3.networklayer.com (173.192.18.225) 121.406 ms 120.453 ms 120.361 ms 13 te3-2.dsr01.dllstx2.networklayer.com (70.87.253.130) 120.158 ms 118.674 ms 118.645 ms 14 po1.car01.dllstx2.networklayer.com (70.87.254.74) 118.616 ms 118.558 ms 118.822 ms 15 5a.7.1243.static.theplanet.com (67.18.7.90) 122.036 ms 119.985 ms 119.083 ms From some other connections I can reach yum,puppetlabs.com without a problem. Anyone else seeing this as well? Is there a solution? Are you able to do: http://www.downforeveryoneorjustme.com/downloads.puppetlabs.com and http://www.downforeveryoneorjustme.com/yum.puppetlabs.com We have had no reports of users being unable to access our software. Are you still seeing these issues? Mike -- 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] Puppet agents stop reporting after master runs out of disk space...
Hi, Puppet's sister project, MCollective would do it. An alternative would be something like Rundeck. Den On 28/01/2012, at 3:52, Kyle Mallory kyle.mall...@utah.edu wrote: I am experiencing a curious event, and wondering if others have seen this... As well, I have a question related to it. Today, I noticed my puppet summary report from Foreman this morning, that 60 of my 160 hosts all stopped reporting at nearly the exact same time, and have not since restarted. Investigating, it appears that my puppetmaster temporarily ran out of disk space on the /var volume, probably in part do to logging. I have log rollers running, which eventually freed up some disk space, but the 60 hosts, have not resumed reporting. If I dig into the logs on one of the failing agents, there are no messages from puppet, past 4am (here is a snippet of my logs): Jan 27 02:44:25 kmallory3 puppet-agent[15340]: Using cached catalog Jan 27 02:44:25 kmallory3 puppet-agent[15340]: Could not retrieve catalog; skipping run Jan 27 03:14:30 kmallory3 puppet-agent[15340]: Could not retrieve catalog from remote server: Error 400 on SERVER: No space left on device - /var/lib/puppet/yaml/facts/kmallory3.xxx.xxx.xxx.yaml Jan 27 03:14:30 kmallory3 puppet-agent[15340]: Using cached catalog Jan 27 03:14:30 kmallory3 puppet-agent[15340]: Could not retrieve catalog; skipping run Jan 27 03:47:30 kmallory3 puppet-agent[15340]: Could not retrieve plugin: execution expired Jan 27 04:01:02 kmallory3 puppet-agent[15340]: Could not retrieve catalog from remote server: execution expired Jan 27 04:01:02 kmallory3 puppet-agent[15340]: Using cached catalog Jan 27 04:01:02 kmallory3 puppet-agent[15340]: Could not retrieve catalog; skipping run Forcing a run of puppet, I get the following message: kmallory3:/var/log# puppetd --onetime --test notice: Ignoring --listen on onetime run notice: Run of Puppet configuration client already in progress; skipping After stopping and restarting the puppet service, the agent started running properly. It appears that the failure from the server has caused the agent to hang, from which it was not able to recover gracefully. Has anyone experienced this before? We are running 2.6.1 on the large majority of our hosts, including this one. Many failed, but 2/3rds keep running properly. Now, on to my question.. Anyone got some bright ideas for how I could force Puppet to restart itself on a 60 machines, when Puppet isn't running?? I'm not really excited by the prospect of logging into 60 machines, and running a sudo command... sigh. --Kyle -- 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] Can't use ${path} in file resource as its namevar?
Thread back from the dead 5 months later :)
Nan, using your code example, I get this with PE 2.0.1:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not match ${ldapclient::params::fileroot}/${name},
at /etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:3
on node rcf-cm-master.our.org
define ldapclient::conf ($mode, $notify = false) {
file { $name:
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
mode = $mode,
if $notify {
notify = Class['ldapclient::service'],
}
require = Class['ldapclient::install'],
}
}
class ldapclient::config {
case $sys_sshortai {
'RH5': {
ldapclient::conf { '/etc/openldap/ldap.conf': mode = '444' }
ldapclient::conf { '/etc/ldap.conf': mode = '444' }
}
'RH6': {
ldapclient::conf { '/etc/openldap/ldap.conf': mode = '444' }
ldapclient::conf { '/etc/nslcd.conf': mode = '444', notify =
true }
}
}
}
--
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/-/_E4djfGmFHEJ.
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: Compiled catalog arount 70s
On Jan 27, 11:10 am, Antidot SAS antidot...@gmail.com wrote: Here are the info you wanted: OS: Debian squeeze Puppet: installed from gem version 2.7.9 As I sayed the hardware is an old Poweredge SC1425 with 4 Xeon 2,8 Ghz with 2 Go of Memory Apparently the code is preety ugly since the compiled time is big, I have just share the code:https://github.com/jmauro/puppet-user The code is pretty, but very complicated, especially for the relatively simple job it seems to be trying to do. Clearly that code is not your first cut at this, so did older versions exhibit the same poor compile times? If you go back through your revision history, perhaps you can find the change that made compile times spike. Also, Brice's suggestion to check for swapping is a good one, especially because Puppet sometimes uses a lot of memory. Although your hardware is a bit old, it should be up to this task so long as it hasn't too many competing demands on it. Since your catalog eventually does compile, it might be useful to look at the result, available in YAML form. You might discover that it is a lot more complicated than you thought, and that would yield clues to what needs to be cut back. If all else fails, try disabling as much of the code as possible, then watch compilation times as you re-enable it bit by bit. I suspect that you will find some particular part that consumes the lion's share of the compilation time. 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: Can't use ${path} in file resource as its namevar?
On Jan 27, 4:34 pm, jblaine cjbla...@gmail.com wrote:
Thread back from the dead 5 months later :)
Nan, using your code example, I get this with PE 2.0.1:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not match ${ldapclient::params::fileroot}/${name},
at /etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:3
on node rcf-cm-master.our.org
define ldapclient::conf ($mode, $notify = false) {
file { $name:
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
mode = $mode,
if $notify {
notify = Class['ldapclient::service'],
}
require = Class['ldapclient::install'],
}
}
class ldapclient::config {
case $sys_sshortai {
'RH5': {
ldapclient::conf { '/etc/openldap/ldap.conf': mode = '444' }
ldapclient::conf { '/etc/ldap.conf': mode = '444' }
}
'RH6': {
ldapclient::conf { '/etc/openldap/ldap.conf': mode = '444' }
ldapclient::conf { '/etc/nslcd.conf': mode = '444', notify =
true }
}
}
}
Your code looks buggy:
1) you cannot use 'if' statements inside resource defnitions
2) you write notify = true where you want notify = true
There are a couple of ways to address the former problem, among them
replacing the 'if' block with a selector. Also, I consider it a
matter of good form to use quotes around strings and to bracket
variable references, so I'd write the definition like this:
define ldapclient::conf ($mode, $notify = false) {
file { ${name}:
source = ${ldapclient::params::fileroot}/${name},
owner = ${ldapclient::params::ldapclient_user},
mode = ${mode},
notify = $notify ? { true = Class['ldapclient::service'],
default = undef },
require = Class['ldapclient::install'],
}
}
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: Can't use ${path} in file resource as its namevar?
John, I've no doubt the code is trash. I'm struggling through what I consider to be an extremely obtuse declarative language. Thank you for the advice. -- 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/-/tEnFCtSCXGwJ. 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] Can't use ${path} in file resource as its namevar?
I think you are missing double quotes around:
${ldapclient::params::fileroot}/${name}
Sent from my iPhone
On Jan 27, 2012, at 17:35, jblaine cjbla...@gmail.com wrote:
Thread back from the dead 5 months later :)
Nan, using your code example, I get this with PE 2.0.1:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not match ${ldapclient::params::fileroot}/${name},
at /etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:3
on node rcf-cm-master.our.org
define ldapclient::conf ($mode, $notify = false) {
file { $name:
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
mode = $mode,
if $notify {
notify = Class['ldapclient::service'],
}
require = Class['ldapclient::install'],
}
}
class ldapclient::config {
case $sys_sshortai {
'RH5': {
ldapclient::conf { '/etc/openldap/ldap.conf': mode = '444' }
ldapclient::conf { '/etc/ldap.conf': mode = '444' }
}
'RH6': {
ldapclient::conf { '/etc/openldap/ldap.conf': mode = '444' }
ldapclient::conf { '/etc/nslcd.conf': mode = '444', notify =
true }
}
}
}
--
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/-/_E4djfGmFHEJ.
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] Can't use ${path} in file resource as its namevar?
Indeed.
Trashing the entire defined resource idea 30 mins ago, and
simply trying:
class ldapclient::config {
case $sys_sshortai {
'RH6': {
file { '/etc/openldap/ldap.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
require = Class['ldapclient::install'],
}
file { '/etc/nslcd.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
require = Class['ldapclient::install'],
notify = Class['ldapclient::service'],
}
}
}
}
is giving me:
err: /Stage[main]/Ldapclient::Config/File[/etc/nslcd.conf]: Could not
evaluate: Could not retrieve information from environment production
source(s) puppet:///modules/ldapclient/files/RH6/ldapclient::config at
/etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:30
err: /Stage[main]/Ldapclient::Config/File[/etc/openldap/ldap.conf]: Could
not evaluate: Could not retrieve information from environment production
source(s) puppet:///modules/ldapclient/files/RH6/ldapclient::config at
/etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:23
This is maddening. What do those errors even mean? So vague :(
--
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/-/ZwWSDMnrqesJ.
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] Help need for resolving the error while bootstrapping a new instance with my puppet master on EC2 instance.
At first, I fired the command: puppet node_aws bootstrap --image ami-0166b168 --keyname Test_Server -- type t1.micro --group default --login root --keyfile /aws_key_pair/ Test_Server.pem I got the error as: notice: Creating new instance ... notice: Creating new instance ... Done notice: Creating tags for instance ... notice: Creating tags for instance ... Done notice: Launching server i-794db51c ... ## notice: Server i-794db51c is now launched notice: Server i-794db51c public dns name: ec2-174-129-96-47.compute-1.amazonaws.com notice: Waiting for SSH response ... notice: Waiting for SSH response ... Done notice: Installing Puppet ... notice: Puppet is now installed on: ec2-174-129-96-47.compute-1.amazonaws.com notice: No classification method selected notice: Signing certificate ... err: Signing certificate ... Failed err: Signing certificate error: Could not render to pson: getaddrinfo: Name or service not known err: exit err: Try 'puppet help node_aws bootstrap' for usage Then again I tried, with the command: puppet node_aws bootstrap --image ami-0166b168 --keyname Test_Server -- type t1.micro --group default --login root --keyfile /aws_key_pair/ Test_Server.pem --mode agent --pe-version 2.0. But it was of no help, this time the error was: notice: Creating new instance ... notice: Creating new instance ... Done notice: Creating tags for instance ... notice: Creating tags for instance ... Done notice: Launching server i-e1b84384 ... ### notice: Server i-e1b84384 is now launched notice: Server i-e1b84384 public dns name: ec2-174-129-103-118.compute-1.amazonaws.com notice: Waiting for SSH response ... notice: Waiting for SSH response ... Done notice: Installing Puppet ... notice: Puppet is now installed on: ec2-174-129-103-118.compute-1.amazonaws.com notice: No classification method selected notice: Signing certificate ... err: Signing certificate ... Failed err: Signing certificate error: Could not render to pson: private method `gsub' called for nil:NilClass err: exit err: Try 'puppet help node_aws bootstrap' for usage [root@domU-12-31-39-0A-42-86 ~]# puppet cert --list [root@domU-12-31-39-0A-42-86 ~]# As you can see above, there is no pending certificate request pending with the master, and the node was created with puppet installed on it, but the certificate generation and signing is getting me this error. But then, I tried to manually connect to my master from the instance created above, i.e. After adding necessary dns entries in /etc/hosts file on both the machine’s files, I went to my agent machine fired the command : puppet agent --server=domU-12-31-39-0A-42-86.compute-1.internal --no- daemonize –verbose This successfully generated a certificate which I had to manually sign at the master, as follows: puppet cert --sign ec2-174-129-103-118.compute-1.amazonaws.com- e6d576ee-45a7-a0fe-2b80-8691d66adfd6 notice: Signed certificate request for ec2-174-129-103-118.compute-1.amazonaws.com-e6d576ee-45a7- a0fe-2b80-8691d66adfd6 notice: Removing file Puppet::SSL::CertificateRequest ec2-174-129-103-118.compute-1.amazonaws.com-e6d576ee-45a7- a0fe-2b80-8691d66adfd6 at '/etc/puppetlabs/puppet/ssl/ca/requests/ ec2-174-129-103-118.compute-1.amazonaws.com-e6d576ee-45a7- a0fe-2b80-8691d66adfd6.pem' After that, I tried using: [root@domU-12-31-39-0C-70-80 /]# puppet node_aws bootstrap --image ami-0166b168 --keyname Test_Server --type t1.micro --group default -- login root --keyfile /aws_key_pair/Test_Server.pem --node-group default --enc-server ec2-184-73-127-22.compute-1.amazonaws.com --enc- port 443 --enc-ssl --enc-auth-user console --enc-auth-passwd puppet notice: Creating new instance ... notice: Creating new instance ... Done notice: Creating tags for instance ... notice: Creating tags for instance ... Done notice: Launching server i-0f649f6a ... ### notice: Server i-0f649f6a is now launched notice: Server i-0f649f6a public dns name: ec2-50-19-37-19.compute-1.amazonaws.com notice: Waiting for SSH response ... notice: Waiting for SSH response ... Done notice: Installing Puppet ... notice: Puppet is now installed on: ec2-50-19-37-19.compute-1.amazonaws.com notice: Contacting https://ec2-184-73-127-22.compute-1.amazonaws.com:443/ to classify ec2-50-19-37-19.compute-1.amazonaws.com- b6d8b475-5693-2f67-844c-72c8647c9f54 notice: Signing certificate ... err: Signing certificate ... Failed err: Signing certificate error: Could not render to pson: getaddrinfo: Name or service not known err: exit err: Try 'puppet help node_aws bootstrap' for usage I am not getting any idea of what this pson is. It is common in all my errors. Can anyone help? Thanks Regards, Ravi -- 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
Re: [Puppet Users] finally have puppet/passenger/dashboard working... new problem
I found this bug in Redmine that sounds like it could be your problem. http://projects.puppetlabs.com/issues/3234 It looks like a long standing issue, but that Nick L is possibly on to a solution. Could you review the ticket to see if this is what is affecting you and if so post your newest info in to help the Open Source team prioritize it? If this isn't what's affecting you please open a new ticket with your information. And of course if the work arounds in the ticket work for you, please let the list know ; ) On Fri, Jan 27, 2012 at 9:16 AM, Peter Berghold salty.cowd...@gmail.comwrote: What the heck does this mean? err: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method `fact_merge' for nil:NilClass warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run Only seems to be happening on one host in particular... -- Peter L. Berghold Owner, Shark River Technical Solutions LLC -- 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] Can't use ${path} in file resource as its namevar?
The errors are good at locating the source of your issues:
err: /Stage[main]/Ldapclient::Config/File[/etc/nslcd.conf]: Could not evaluate:
Could not retrieve information from environment production source(s)
puppet:///modules/ldapclient/files/RH6/ldapclient::config at
/etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:30
Line 30 of your config.pp is where your problem lies (one of them anyway). It
can't find the source file.
file { '/etc/nslcd.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
require = Class['ldapclient::install'],
notify = Class['ldapclient::service'],
}
So it is interpreting this:
${ldapclient::params::fileroot}/${name},
As:
puppet:///modules/ldapclient/files/RH6/ldapclient::config
The following will give detail about fileserving, but $name is probably not
resolving to what you think it should:
http://docs.puppetlabs.com/guides/file_serving.html
How are you declaring this in your manliest. What do you think $name should
be? Try putting in the source path without the variable substitution.
Den
On 28/01/2012, at 10:17, jblaine cjbla...@gmail.com wrote:
puppet:///modules/ldapclient/files/RH6/ldapclient::config at
/etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:30
--
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] Can't use ${path} in file resource as its namevar?
On Fri, Jan 27, 2012 at 3:17 PM, jblaine cjbla...@gmail.com wrote:
Indeed.
Trashing the entire defined resource idea 30 mins ago, and
simply trying:
class ldapclient::config {
case $sys_sshortai {
'RH6': {
file { '/etc/openldap/ldap.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
require = Class['ldapclient::install'],
}
file { '/etc/nslcd.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
owner = $ldapclient::params::ldapclient_user,
require = Class['ldapclient::install'],
notify = Class['ldapclient::service'],
}
}
}
}
is giving me:
err: /Stage[main]/Ldapclient::Config/File[/etc/nslcd.conf]: Could not
evaluate: Could not retrieve information from environment production
source(s) puppet:///modules/ldapclient/files/RH6/ldapclient::config at
/etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:30
err: /Stage[main]/Ldapclient::Config/File[/etc/openldap/ldap.conf]: Could
not evaluate: Could not retrieve information from environment production
source(s) puppet:///modules/ldapclient/files/RH6/ldapclient::config at
/etc/puppetlabs/puppet/modules/ldapclient/manifests/config.pp:23
In the link Den provided, you'll want to check the puppet:/// syntax. You
don't want to include the 'files' directory in the puppet:/// reference.
You'll want to use puppet:///modules/ldapclient/RH6/config_file for a file
located in $modulepath/ldapclient/files/RH6/config_file. By default,
using puppet:///, it looks to the files directory, so you don't need to
pass it.
This is maddening. What do those errors even mean? So vague :(
--
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/-/ZwWSDMnrqesJ.
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
--
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] Can't use ${path} in file resource as its namevar?
Den and Gary, thanks for the replies.
I am trying to re-use the title (as I understand it). Can I not do that?
Do I have to type the name of the file as the title and also at the
end of my source = ${ldapclient::params::fileroot}/..., ?
Gary, I've removed '/files' as part of ${ldapclient::params::fileroot}
Setting the source to the explicit filename (typing it again) works,
but seems silly to me.
--
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/-/UHLy-Jk_I9YJ.
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.
