Re: [Puppet Users] Re: Cross-module dependencies
Hi, On 01/28/2012 04:35 PM, Trevor Vaughan wrote: Drawbacks: * Requires the user to have an explicit working knowledge of all modules and namespaces * Adds a lot of random logic to the code (unless it becomes a metaparam of some sort) You skipped the most important drawback: Commitment to parameterized classes. The fact that there can be only one place that includes those classes, and that this singular place must have the whole picture of what requirements are met, is conceivably a show stopper from my point of view. This will work for people that have a functional ENC, I guess, but should that be a requirement for using Forge modules? Furthermore, how can modules hope to ever interoperate like this? If all module classes get parameterized, it will be outright impossible for one module to ever include another module's classes. Say module A includes class B::C. As soon as a user installs module A in addition to B, they have to clean their manifests of inclusions of B::C. On 01/29/2012 07:39 AM, Brian Gupta wrote: It frightens me a bit that I think the correct solution, will be to replicate what the distros are doing in Puppetforge. Basically turning puppetforge into a massive cross distro metadata repo, with very strict contribution standards and rules. This would involve strong rules for curated modules that would require manpower to vet (and to contribute the modules). I honestly don't see the problem. Imagine CPAN was limited to downloads of tarballs from the website (or even souce control checkouts). I disbelieve it would be as significant today as it has become. The same goes for Ruby Gems and all such systems. As this seems to be a recurring theme: Am I wrong to compare these to the Forge? Sincerely, 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] Anyone know a good tool for 'watching' configurations?
NixFU wrote (ao):
We don't frankly see having all our application teams use puppet or
anything else to actively manage their applications. What we would
like to do is watch the applications and know when things change.
Basically, watch the directories that the developers put their
applications into and keep a history of what changes and when.
[..]
But I was wondering if anyone knows of a tool that would do this type
of function and provide some human friendly data and reports etc..
What about 'audit'?
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.0
===
Audit Metaparameter
Puppet now supports an audit metaparameter in the style of Tripwire.
Using this new metaparameter we can specify our resource like:
file { '/etc/hosts':
audit = [ owner, group, mode ],
}
Now instead of changing each value (though you can change it too if you
wish) Puppet will instead generate auditing log messages, which are
available in your standard Puppet reports:
audit change: previously recorded value owner root has been changed to
owner james
This allows you to track any changes that occur on resources under
management on your hosts. You can specify this audit metaparameter for
any resource and all their attributes and track users, groups, files,
services and the myriad of other resources Puppet can manage.
You can also specify the special value of all to have Puppet audit every
attribute of a resource rather than needing to list all possible
attributes, like so:
file { '/etc/hosts':
audit = all,
}
You can also combine the audited resources with managed resources
allowing you to manage some configuration items and simply track others.
It is important to remember though, unlike many file integrity systems,
that your audit state is not protected by a checksum or the like and is
stored on the client in the state.yaml file. In future releases we will
look at protecting and centralising this state data.
===
Sander
--
Humilis IT Services and Solutions
http://www.humilis.net
--
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 01/28/2012 12:17 AM, jblaine wrote:
Trashing the entire defined resource idea 30 mins ago, and
simply trying:
But why?
class ldapclient::config {
case $sys_sshortai {
'RH6': {
file { '/etc/openldap/ldap.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
You're back to square one. $name is nothing sensible in this context.
It's the name of the class this appears inside of - 'ldapclient::config'.
For automatic URL composition by use of the file path, you definitely do
want to wrap the file resource in a defined type like you were trying
earlier!
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
Had a bunch more thoughts on this topic, and I feel I agree with Brian: a forge with one module for every purpose, supported maybe by library modules (like linux) would be the best. It would mean consolidating the 17 ssh modules that exist now into one all encompassing ssh module. In the case of SSH that is totally doable, but consider the 300 gazillion different use cases of apache and things get interesting. I think this would mean we'd have appointed maintainers for each module, and if possible a puppetlabs provided jenkins install (with community provided jenkins slaves?) that would do the CI testing every night. That would then make it possible to have an auto-updated overview for each module of the latest supported OS's for puppet, and wether that module passes tests for that OS. This seems like a massive undertaking from where we are now, but it would in the end make all of our lives a ton easier (one trusted source for good high quality modules) and reduce the 'problem' of inter-module dependencies to a minimum. Of course it still exists for in-house applications that are being puppetised, but it would already mean the world if they would be able to depend on what the public trusted modules define. I personally like the way the drupal module projects work: anyone can start a project, but they are all hosted on the drupal.org site within drupal.org version control, and they have teams of code reviewers maintaining integrity of the module base that lives on drupal.org. cheers, Walter On Mon, Jan 30, 2012 at 10:51, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Hi, On 01/28/2012 04:35 PM, Trevor Vaughan wrote: Drawbacks: * Requires the user to have an explicit working knowledge of all modules and namespaces * Adds a lot of random logic to the code (unless it becomes a metaparam of some sort) You skipped the most important drawback: Commitment to parameterized classes. The fact that there can be only one place that includes those classes, and that this singular place must have the whole picture of what requirements are met, is conceivably a show stopper from my point of view. This will work for people that have a functional ENC, I guess, but should that be a requirement for using Forge modules? Furthermore, how can modules hope to ever interoperate like this? If all module classes get parameterized, it will be outright impossible for one module to ever include another module's classes. Say module A includes class B::C. As soon as a user installs module A in addition to B, they have to clean their manifests of inclusions of B::C. On 01/29/2012 07:39 AM, Brian Gupta wrote: It frightens me a bit that I think the correct solution, will be to replicate what the distros are doing in Puppetforge. Basically turning puppetforge into a massive cross distro metadata repo, with very strict contribution standards and rules. This would involve strong rules for curated modules that would require manpower to vet (and to contribute the modules). I honestly don't see the problem. Imagine CPAN was limited to downloads of tarballs from the website (or even souce control checkouts). I disbelieve it would be as significant today as it has become. The same goes for Ruby Gems and all such systems. As this seems to be a recurring theme: Am I wrong to compare these to the Forge? Sincerely, 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. -- 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is annoying to have everything in a single place that defines the state of
your nodes but, as you point out, this seems to be the model if you're
using an ENC and that seems to be the recommended practice across the mailing
list for any sort of scale.
But, you don't need a functional ENC to make this work, you simply need to have
everything defined at the top level whether it be via node, higher
level class, or ENC.
The main issue here seems to be modules that are trying to be too helpful
from my reading of the mailing list.
It seems that many would like this to be an anti-pattern:
class foo {
if not defined(Class['bar']) {
include 'bar'
bar::baz { ... }
}
}
include 'foo'
Instead, you should be less helpful, and do the following:
include 'foo'
include 'bar'
bar::baz { ... }
So, instead of doing something like, say, setting up IPTables in your module
(thus creating a cross-module dependency), you should do all of this in
one monolithic place at the node level or a higher level aggregation class
level.
While this keeps your modules clean, it seems like a lot more effort to
maintain since the module for nginx should really know what ports it's using
and know how to set up its own firewall rules.
So, the tradeoff is an ENC vs. a large collection of cluttered classes at the
top level to make sure you don't have cross-module dependencies.
I'm not sure if either is better (or if either is any good at all) but they're
both functional.
The ability to tag modules as requiring other modules of a particular version
(ala CPAN, Gems, everything else) would solve this issue as Puppet
would be able to check to make sure that you have the correct version of the
modules installed prior to compiling the catalog.
Trevor
On 01/30/2012 03:51 AM, Felix Frank wrote:
Hi,
On 01/28/2012 04:35 PM, Trevor Vaughan wrote:
Drawbacks:
* Requires the user to have an explicit working knowledge of all
modules and namespaces
* Adds a lot of random logic to the code (unless it becomes a
metaparam of some sort)
You skipped the most important drawback: Commitment to parameterized
classes. The fact that there can be only one place that includes those
classes, and that this singular place must have the whole picture of
what requirements are met, is conceivably a show stopper from my point
of view.
This will work for people that have a functional ENC, I guess, but
should that be a requirement for using Forge modules?
Furthermore, how can modules hope to ever interoperate like this? If all
module classes get parameterized, it will be outright impossible for one
module to ever include another module's classes.
Say module A includes class B::C. As soon as a user installs module A in
addition to B, they have to clean their manifests of inclusions of B::C.
On 01/29/2012 07:39 AM, Brian Gupta wrote:
It frightens me a bit that I think the correct solution, will be to
replicate what the distros are doing in Puppetforge. Basically turning
puppetforge into a massive cross distro metadata repo, with very strict
contribution standards and rules. This would involve strong rules for
curated modules that would require manpower to vet (and to
contribute the modules).
I honestly don't see the problem. Imagine CPAN was limited to downloads
of tarballs from the website (or even souce control checkouts). I
disbelieve it would be as significant today as it has become.
The same goes for Ruby Gems and all such systems.
As this seems to be a recurring theme: Am I wrong to compare these to
the Forge?
Sincerely,
Felix
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvaug...@onyxpoint.com
phone: 410-541-ONYX (6699)
pgp: 0x6C701E94
- -- This account not approved for unencrypted sensitive information --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJPJoUxAAoJECNCGV1OLcyp7igH/0rroAjC8Ewc9Aw2bdE7gO0N
0KfvzYCTZtJLFTBeNIAErliWd9iR5W84H0j8KJGjPg18qcRcDHjC/hnf5+GV8lIS
6kG3EgwYwyDg8Xc0qAbWubJv7bJ29X4Fc8CCHkq13CkXFM/OqnKpUbXA6X6+o5a/
Hv5Z6WXQjPC7uCupwyqktkjj5sjwvdgniSvKsj6EK3bhGRyMsvJAzmDjucwcRNsM
vz6IG05aFJrYTUp0rZzTJf/HjIPgmD90puoXXSa/RVQnsb3WSw0AwYe1jBAHWap4
pDw+F2qrMdwc9XgQv4ZFFNp/A1OCFh21uW3B1D7XjM+U3QRpmXTKhX71lcqbX08=
=XRv1
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-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.
attachment: tvaughan.vcf
[Puppet Users] Re: intermodule dependency
On Jan 23, 3:45 am, Jos Houtman j...@hyves.nl wrote: Hello list, I am looking for advice/best-practices on how to handle inter module dependency's. [...] Without stages we tried three ways of doing this: Creating a dependency chain between classes. Class['Ldap'] - Class['Mysql']. This is very easy to do, but doesn't work if we inherit from Ldap, say: class ldap::server inherits ldap The ordering between ldap::server and Mysql is not guaranteed. It also requires the maintainer of the ldap module to know about all modules that depend on ldap and update them if he decides to inherit. A task that is likely to be forgotten. That's one of many reasons to not do that. Specifically, one should employ class inheritance only when it involves overriding resource properties of the parent class. Where all you really want is to compose classes (as I infer is the case you describe), you should instead use the 'include' function, the 'require' function, or a resource-style class declaration. If you use class inheritance *only* to override resource properties (subclass bodies contain nothing but resource overrides) then I think your subclasses will not suffer from the problem you describe. That's a more restrictive rule than I impose on myself, but it might be useful to you. You will already have recognized that none of this solves your problem directly. Effective dependency management requires discipline, planning, documentation, and the occasional large-scale refactoring. Correct use of class inheritance fits in mostly by shaping the expectations and practices of manifest developers, rather than by providing tools to directly control ordering. I hope you nevertheless find this useful. 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] Can't use ${path} in file resource as its namevar?
On Monday, January 30, 2012 4:41:40 AM UTC-5, Felix.Frank wrote:
On 01/28/2012 12:17 AM, jblaine wrote:
Trashing the entire defined resource idea 30 mins ago, and
simply trying:
But why?
Felix, thanks for the reply.
I was just trying stuff out while waiting to see what fleshed out here in
the group.
class ldapclient::config {
case $sys_sshortai {
'RH6': {
file { '/etc/openldap/ldap.conf':
mode = '444',
source = ${ldapclient::params::fileroot}/${name},
You're back to square one. $name is nothing sensible in this context.
It's the name of the class this appears inside of - 'ldapclient::config'.
So there's nothing I can refer to inside a basic file resource declaration
which refers to the file resource title. That's what I wanted to know
(assuming I understand everyone correctly).
--
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/-/agJ8hb6e5-oJ.
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 01/30/2012 03:50 PM, jblaine wrote: So there's nothing I can refer to inside a basic file resource declaration which refers to the file resource title. That's what I wanted to know (assuming I understand everyone correctly). That's correct, yes. -- 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 30, 2:51 am, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
Hi,
On 01/28/2012 04:35 PM, Trevor Vaughan wrote: Drawbacks:
* Requires the user to have an explicit working knowledge of all
modules and namespaces * Adds a lot of random logic to the code (unless it
becomes a
metaparam of some sort)
You skipped the most important drawback: Commitment to parameterized
classes. The fact that there can be only one place that includes those
classes, and that this singular place must have the whole picture of
what requirements are met, is conceivably a show stopper from my point
of view.
+1
This will work for people that have a functional ENC, I guess, but
should that be a requirement for using Forge modules?
Furthermore, how can modules hope to ever interoperate like this? If all
module classes get parameterized, it will be outright impossible for one
module to ever include another module's classes.
Say module A includes class B::C. As soon as a user installs module A in
addition to B, they have to clean their manifests of inclusions of B::C.
Right. The approach depends on using class parameters to pass
requirements, but it depends on classes being *un*parameterized to
apply those requirements -- catch-22. There is a solution to that
particular problem, however: define requirements via external
[meta]data instead of via parameters.
That's not to say I like the proposal, however. I don't. In fact I
think it's completely inside-out. Classes should *know* what other
classes they depend upon; they should not need to be told.
Moreover, I don't see what is gained by passing requirements as
parameters rather than, say, having the user separately declare
optional classes that carry the same information. For example,
instead of a structure requiring this:
class { 'foo': reqs = ['bar'] }
it should be possible to structure a module's classes so that you can
do this instead:
include 'foo::bar'
include 'foo'
(perhaps in the opposite order).
On 01/29/2012 07:39 AM, Brian Gupta wrote:
It frightens me a bit that I think the correct solution, will be to
replicate what the distros are doing in Puppetforge. Basically turning
puppetforge into a massive cross distro metadata repo, with very strict
contribution standards and rules. This would involve strong rules for
curated modules that would require manpower to vet (and to
contribute the modules).
I honestly don't see the problem. Imagine CPAN was limited to downloads
of tarballs from the website (or even souce control checkouts). I
disbelieve it would be as significant today as it has become.
The same goes for Ruby Gems and all such systems.
As this seems to be a recurring theme: Am I wrong to compare these to
the Forge?
Yes and no.
On one hand, clearly there are structural similarities between, say,
Puppet modules and Perl modules. The Forge serves a similar role for
the former to the role CPAN serves for the latter. I can totally see
the usefulness of tools for automatically installing and removing
Forged Puppet modules.
On the other hand, there are several problems with adopting such an
approach to solve the Puppet module dependency issue, among them:
1) The Forge doesn't address the problem AT ALL as it now stands. The
relevant resource that package management systems offer is not the
packages themselves (which the Forge has), but rather the metadata
database that each system relies on. Defining, building, and
maintaining such a database would be a massive and ongoing endeavor,
quite separate from developing and managing the Puppet and module
codebases.
2) A package management system would only work around the problem, not
solve it, and then only among modules from the same repository.
3) In fact, it would not really be the package management system
itself that made anything work. Instead, authors of Forge modules
would still need to find some way to make their modules interoperate,
and Forge curators would need somehow to ensure that they did. All
the management software would really contribute is a dependency-aware
ability to automatically install/remove packages. The system overall
would provide a promise that the particular modules it contains all do
work together, but that's altogether different from a means by which
anyone -- the Forge or otherwise -- can fulfill such a promise.
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] Re: Cross-module dependencies
On Sat, Jan 28, 2012 at 10:39 PM, Brian Gupta brian.gu...@brandorr.comwrote: Nigel, It frightens me a bit that I think the correct solution, will be to replicate what the distros are doing in Puppetforge. Basically turning puppetforge into a massive cross distro metadata repo, with very strict contribution standards and rules. This would involve strong rules for curated modules that would require manpower to vet (and to contribute the modules). It's worth pointing out here that a massive cross distro repository of modules doesn't necessarily require strict contribution standards and rules. There are other options to ensure that high quality modules are available other than creating a high barrier to entry for the modules themselves. Exposing community opinion on modules and success rates of people deploying them can help us all achieve the same goal. What kind of a repository do we want? -- Nigel Kersten Product Manager, 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.
[Puppet Users] Re: Mining hash field out of the /etc/shadow shadow file
Olivier.
here is what the password part of our user resources looks like.
The actual command is just a wrapper around finding the crypt and
returning something appropriate.
password = generate('/site/bin/getups', '-u', $name),
Make sure the script you are calling with generate returns a shadow
entry without a trailing newline. I would also make sure the script
never returns an empty string or any OS specific values that would
create a shell account without a password.
As jeff mentioned you'll run into some permissions problems so
you'll need to either have an independent process dumping user/hashes
to file readable by the puppet user or allow puppet to read the shadow
file via sudo or something.
HTH
On Jan 29, 8:20 pm, Aaron Grewell aaron.grew...@gmail.com wrote:
Since it's the shell redirection that Puppet seems not to like, why not
wrap the commands in a shell script and use generate on that?
On Jan 29, 2012 6:18 PM, Olivier ofran...@gmail.com wrote:
and then lookup the hash in the /etc/shadow file
or use the mkpasswd utility (with which I am not familiar)
Once you have the hashed value of your desired clear text password
you can copypaste that in the user definition.
-Stefan
your answer is just the text of my original question. So the question
still stands: how do I get the hashed value from /etc/shadow?
Here is the background of my problem. I have 40 puppet clients and one
master. The password of each user expires after 90 days. Instead of
changing their password manually on 40 different servers by logging
into each server,each user will have to change his/her password on the
puppet server only and Puppet will replicate the hash value on each
puppet client. Obviously I will never know the user's password and am
not interested in replicating the root password. NIS and LDAP are not
an option.
Thank you.
--
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] SLES11: facter without arguments produces Error: uninitialized constant Facter::IPAddress
Hi, I run into problems with the ipaddress fact using the latest Facter gem (1.6.4, 1.6.5) on SLES11. The versions and gems I use work perfectly fine on SLES10 SP3. The problem: running facter without arguments results in an error, even though the erroring fact ipaddress is ok. test:~ # cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 test:~ # ruby --version ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux] test:~ # gem --version 1.3.5 test:~ # puppet --version 2.7.9 test:~ # facter --version 1.6.5 test:~ # facter kernel Linux test:~ # facter ipaddress xx.xx.xxx.xxx (ip address is ok) test:~ # facter The interpreter parameter to 'setcode' is deprecated and will be removed in a future version. Error: uninitialized constant Facter::IPAddress test:~ # -- 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,
thanks for your elaborate design sketch.
Sorry for limiting my quote severely.
On 01/30/2012 06:28 PM, Nick wrote:
+package { 'libfoo': ensure = present }
Is this different from John's constraint proposal?
To me this didn't become clear: Does the manifest still need to declare
an actual package { libfoo } somewhere, or is this implied by at least
one assertion regarding any of its parameters?
Of the latter is the case, then this is not different from just allowing
puppet to consume multiple declarations of the same resource, along with
all the oft-discussed difficulties.
If instead, there still is that one central resource declaration
somewhere, I'm pretty sure this is the same as constraints.
Which is probably a really neat idea.
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] SSL Errors - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B
Hi, concerning your question why everything seems to work pretty well: On 01/27/2012 04:59 AM, Romeo Theriault wrote: Jan 26 17:09:41 ppt01 puppet-agent[27357]: Using cached catalog Your agent is using a cached catalog. puppet agent --test should fail. Also, changing the manifest for this node should not have any effect until you resolve this problem. My guess is that the agent has an old master certificate stored or somesuch. For some reason it regards your current master cert as invalid. The simplest approach may be to scrutinize the local /var/lib/puppet/ssl for certificates that match your master's FQDN (perhaps puppet). If you find several, use openssl x509 to find out how they differ. 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] SLES11: facter without arguments produces Error: uninitialized constant Facter::IPAddress
This smells like you have a second copy of facter or some other facts somewhere in your RUBYLIB, as the latest version no longer uses Facter::IPAddress. Are you sure you haven't got an RPM or local copy installed somewhere else? Try running facter --trace as well so we can see the output. The paths might give a clue as to where its traversing on the filesystem. ken. On Mon, Jan 30, 2012 at 7:42 AM, Sven Sporer s...@intothespirit.com wrote: Hi, I run into problems with the ipaddress fact using the latest Facter gem (1.6.4, 1.6.5) on SLES11. The versions and gems I use work perfectly fine on SLES10 SP3. The problem: running facter without arguments results in an error, even though the erroring fact ipaddress is ok. test:~ # cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 test:~ # ruby --version ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux] test:~ # gem --version 1.3.5 test:~ # puppet --version 2.7.9 test:~ # facter --version 1.6.5 test:~ # facter kernel Linux test:~ # facter ipaddress xx.xx.xxx.xxx (ip address is ok) test:~ # facter The interpreter parameter to 'setcode' is deprecated and will be removed in a future version. Error: uninitialized constant Facter::IPAddress test:~ # -- 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...
- Original Message - Thanks guys.. I'll check out mcollective. Yeah, the root password 60 times is a bit painful, but the ssh loop would help. If I remember right, there is an API/REST call for Foreman that will give me a list of the hosts not responsive. The problem here is that puppet was in memory, and running. It just wasn't responsive, perhaps waiting for something to happen that never did. So, checks for the process (monit/snmp/pgrep), etc would say that puppet is fine. Are there any more bullet-proof ways of watch-dogging Puppet specifically? Could we kill the process if catalog locks are more than 30 minutes old? Or are locks on the catalog even a reality? Is this something Puppet could do on its own, in a separate thread, or does it need a new process? I'm just throwing an idea or two. Times I've seen this happen is when the network connection to the master dies at just the right (wrong) time so the Ruby VM gets stuck on blocking IO which it can never recover from. So a supervisor thread wont do - it would also be blocked. I've written a monitor script for puppet that uses the new last_run_summary.yaml file to figure out if puppet has recently run and I monitor that with nagios and nrpe. So at least I know when this happens https://github.com/ripienaar/monitoring-scripts/blob/master/puppet/check_puppet.rb -- 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] File path resolution oddity in puppet nginx+thin setup.
For the purposes of this email I need to make a distinction between my
Production puppet master and my Development puppet master. In either
case, my /etc/puppet/puppet.conf is:
[main]
ssldir=$vardir/ssl
[master]
certname=puppet
Development puppet master is run:
# puppetmasterd --debug --no-daemonize
and Production puppet master is a thin/nginx affair. Please find the
relevant nginx configuration files in this gist:
https://gist.github.com/1706549 and the thin configuration in this
gist: https://gist.github.com/1706558
Using https://github.com/plathrop/puppet-module-supervisor I find that
the source line path in manifests/init.pp causes a 404 when running in
Production mode:
'/etc/logrotate.d/supervisor':
source = 'puppet:///modules/supervisor/logrotate',
require = Package[$supervisor::params::package];
but if I modify the path to be simply 'puppet:///supervisor/logrotate'
all is well. The first and second form succeed in Development mode.
It's my understanding that the first form is _correct_ and that my
Production mode should have no issues with it.
Running 'puppet agent --test' when master is configured in Production
mode results in:
# puppet agent --test
info: Caching catalog for puppet.troutwine.us
info: Applying configuration version '1327955332'
err: /Stage[main]/Supervisor/File[/etc/logrotate.d/supervisor]/ensure:
change from absent to file failed: Could not set 'file on ensure:
Error 404 on SERVER: html
headtitle404 Not Found/title/head
body bgcolor=white
centerh1404 Not Found/h1/center
hrcenternginx/1.1.8/center
/body
/html
at /etc/puppet/modules/supervisor/manifests/init.pp:32
notice: Finished catalog run in 1.89 seconds
and the logs from /var/log/nginx/access.log
# cat /var/log/nginx/{access,error}.log
127.0.1.1 - - [30/Jan/2012:20:50:58 +] POST
/production/catalog/puppet.troutwine.us HTTP/1.1 200 13290 - Ruby
127.0.1.1 - - [30/Jan/2012:20:51:00 +] GET
/production/file_metadata/modules/supervisor/logrotate? HTTP/1.1 200
308 - Ruby
127.0.1.1 - - [30/Jan/2012:20:51:00 +] GET
/production/file_content/modules/supervisor/logrotate HTTP/1.1 404
168 - Ruby
127.0.1.1 - - [30/Jan/2012:20:51:01 +] PUT
/production/report/puppet.troutwine.us HTTP/1.1 200 14 - Ruby
2012/01/30 20:51:00 [error] 10716#0: *222 open()
/etc/puppet/modules/modules/files/supervisor/logrotate failed (2: No
such file or directory), client: 127.0.1.1, server: , request: GET
/production/file_content/modules/supervisor/logrotate HTTP/1.1, host:
puppet:8140
Details about my environment:
# puppet --version
2.7.9
# cat /etc/debian_version
6.0.3
# ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i486-linux]
Anyone have an inkling of what's going wrong?
--
Brian L. Troutwine
--
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 30/01/12 17:48, Felix Frank wrote:
Hi,
thanks for your elaborate design sketch.
Sorry for limiting my quote severely.
On 01/30/2012 06:28 PM, Nick wrote:
+package { 'libfoo': ensure = present }
Is this different from John's constraint proposal?
It did sound similar, yes - but unless I misunderstand it, not identical. For
example, I don't understand how Constraints would avoid the problems with
unifying resources that Nan mentioned.
John's example appeared to be wrapping an existing Resource with something which
puts constraints on it, i.e. a layer on top of Resources. It implies a regular
Resource to wrap somewhere.
Whereas what I had in mind was something which in principle at least, was more
basic than a Resource. With an Assertion there is nothing being managed, or
mutated, by definition. It defines conditions on a resource (lower-case 'r')
which can be checked, and merged, but doesn't imply that any Resource
(upper-case 'R') need to be declared. It's quite possible that one wouldn't
bother, if you don't need to manage or mutate anything.
So Resources (upper case 'R') could be thought of as extensions to Assertions
which also supply rules to mutate a system's state, should the conditions of the
Assertion not be met, so that the conditions *are* met.
To me this didn't become clear: Does the manifest still need to declare
an actual package { libfoo } somewhere, or is this implied by at least
one assertion regarding any of its parameters?
To be explicit: if an Assertion +package { libfoo: } is declared, it just
means libfoo must be installed for this manifest to work. I don't think it
needs to mandate a declaration of a full-blown package { libfoo: } somewhere.
In fact, I can probably imagine circumstances when something might be invoked
which indirectly takes care of the libfoo package (or file, or whatever) - and
then being forced to manage the libfoo package in Puppet just because you want
to assert its presence could be a liability.
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.
[Puppet Users] Re: File path resolution oddity in puppet nginx+thin setup.
All,
I ended up posting the question to ServerFault, where it was answered.
http://serverfault.com/questions/355214/why-does-this-nginx-thin-run-puppet-master-interpret-paths-differently-than-a-lo
On Mon, Jan 30, 2012 at 3:54 PM, Brian Troutwine br...@troutwine.us wrote:
For the purposes of this email I need to make a distinction between my
Production puppet master and my Development puppet master. In either
case, my /etc/puppet/puppet.conf is:
[main]
ssldir=$vardir/ssl
[master]
certname=puppet
Development puppet master is run:
# puppetmasterd --debug --no-daemonize
and Production puppet master is a thin/nginx affair. Please find the
relevant nginx configuration files in this gist:
https://gist.github.com/1706549 and the thin configuration in this
gist: https://gist.github.com/1706558
Using https://github.com/plathrop/puppet-module-supervisor I find that
the source line path in manifests/init.pp causes a 404 when running in
Production mode:
'/etc/logrotate.d/supervisor':
source = 'puppet:///modules/supervisor/logrotate',
require = Package[$supervisor::params::package];
but if I modify the path to be simply 'puppet:///supervisor/logrotate'
all is well. The first and second form succeed in Development mode.
It's my understanding that the first form is _correct_ and that my
Production mode should have no issues with it.
Running 'puppet agent --test' when master is configured in Production
mode results in:
# puppet agent --test
info: Caching catalog for puppet.troutwine.us
info: Applying configuration version '1327955332'
err: /Stage[main]/Supervisor/File[/etc/logrotate.d/supervisor]/ensure:
change from absent to file failed: Could not set 'file on ensure:
Error 404 on SERVER: html
headtitle404 Not Found/title/head
body bgcolor=white
centerh1404 Not Found/h1/center
hrcenternginx/1.1.8/center
/body
/html
at /etc/puppet/modules/supervisor/manifests/init.pp:32
notice: Finished catalog run in 1.89 seconds
and the logs from /var/log/nginx/access.log
# cat /var/log/nginx/{access,error}.log
127.0.1.1 - - [30/Jan/2012:20:50:58 +] POST
/production/catalog/puppet.troutwine.us HTTP/1.1 200 13290 - Ruby
127.0.1.1 - - [30/Jan/2012:20:51:00 +] GET
/production/file_metadata/modules/supervisor/logrotate? HTTP/1.1 200
308 - Ruby
127.0.1.1 - - [30/Jan/2012:20:51:00 +] GET
/production/file_content/modules/supervisor/logrotate HTTP/1.1 404
168 - Ruby
127.0.1.1 - - [30/Jan/2012:20:51:01 +] PUT
/production/report/puppet.troutwine.us HTTP/1.1 200 14 - Ruby
2012/01/30 20:51:00 [error] 10716#0: *222 open()
/etc/puppet/modules/modules/files/supervisor/logrotate failed (2: No
such file or directory), client: 127.0.1.1, server: , request: GET
/production/file_content/modules/supervisor/logrotate HTTP/1.1, host:
puppet:8140
Details about my environment:
# puppet --version
2.7.9
# cat /etc/debian_version
6.0.3
# ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i486-linux]
Anyone have an inkling of what's going wrong?
--
Brian L. Troutwine
--
Brian L. Troutwine
--
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] agent runs mysteriously truncated
Recently I rigged up a script to email me a list of agents that did not send any reports to puppet server in last 24 hours. Each night it lists about a dozen agents, mostly but not always the same ones. They share a common pattern: Agent is running in deamon mode but makes no updates. Each time the agent kicks a run the only impact is to write the following to /var/lib/puppet/state/last_run_summary.yaml: --- time: last_run: 1327963581 /var/lib/puppet/state/puppetdlock gets created and removed as normal. No other file in /var/lib/puppet gets touched. No messages get logged in either client or server. Not report gets sent to server. Restarting puppet agent or rebooting the node does not fix the problem. Running puppet agent -t works fine. Most agents in our site do not show this problem. I have confirmed all agents are running the same versions of puppet, ruby and linux kernel: Distro is SLES11-SP1-x86_64 2.6.32.46-0.3-default puppet-2.7.9-11.1 ruby-1.8.7.p72-5.30.5 facter-1.5.8-3.1 Starting puppet agent with debug flag shows no additional info, since nothing gets logged at all. but I am sure there are other options/tricks I don't know. -- -ashley Did you try poking at it with a stick? -- 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] Conditionally replace in file type
2012/1/26 Juan José Presa Rodal juan...@gmail.com:
(I noted that; since this topic was followed up elsewhere I figured to
repeat myself. :)
Ok Daniel, thanks for your reply, but I have not control about these
individual noreplace files because are $hostname dependent.
Generally, what we would encourage is then that you define them on a
per-hostname basis. You can do that at the node level, or you can
push that down through a define or parameterized class, but the key is
to model that - on a per host basis.
I assume you meant they are different on every host, rather than
literally being a file with the hostname in it; for that you could
just go with `file { /path/to/${hostname}.cfg: ... }` to define the
files. :)
hostname1/home/user/foo/bar/johndoe05/file1.cfg
hostname2/home/user/foo/bar/maryjoe02/file1.cfg
That was the reason for I need something recursive, similar to ignore
parameter. (Or a workaround)
Define them per-node. :)
node hostname1 {
# define it in the node
include common::stuff
file { /home/user/foo/bar/johndoe05/file1.cfg: ... }
# use a parameterized class
class { something::else: configpath = /home/user/foo/bar/johndoe05 }
# ...or a define.
some::define { whatever: configpath = /home/user/foo/bar/johndoe05 }
}
--
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
