[Puppet Users] Re: Can anyone recommend a module with a resource managing a block of lines in a file?
Hi, On Sunday, May 5, 2013 2:25:02 AM UTC+3, Schofield wrote: I'm hoping a commonly used module that provides a resource for managing multiple contiguous lines in a file already exists and someone can point me to it. I want something like the file_line type in the puppet labs stdlib module but have it check multiple lines instead of just one. Have you looked at using templates? If not, then do that first. In case templates don't work out, maybe the concat module does: https://github.com/ripienaar/puppet-concat Cheers, Paul -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Practices: what _not_ to manage with Puppet?
Well, I'll tell you that for now some kind of configuration is difficult to be done with puppet. At least I couldn't find a way to do it. Ex: controlling a /etc/passwd file but partially with a libnss compat syntax. This means entries of local users are no controlled but entries beginning with a '+' are. As I couldn't find a way to do it, for now it is not being controlled by puppet. Em sexta-feira, 3 de maio de 2013 15h02min18s UTC-3, Martin Langhoff escreveu: While I prep my scripts and tool up for a large infra, I want to revisit a question that I ask myself regularly: what do people not manage with Puppet (or wish they weren't)? In my situation (a RH-style world), initial base system install, inc disk layout and initial networking is handled with kickstart For example: Do you exclude mountpoints? Network/SAN mountpoints? Advanced network configs? What are the reasons to exclude a particular item? How do you manage it instead? cheers, m -- martin@gmail.com javascript: - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Can anyone recommend a module with a resource managing a block of lines in a file?
On Monday, May 6, 2013 2:55:33 AM UTC-5, Paul Tötterman wrote: Hi, On Sunday, May 5, 2013 2:25:02 AM UTC+3, Schofield wrote: I'm hoping a commonly used module that provides a resource for managing multiple contiguous lines in a file already exists and someone can point me to it. I want something like the file_line type in the puppet labs stdlib module but have it check multiple lines instead of just one. Have you looked at using templates? If not, then do that first. In case templates don't work out, maybe the concat module does: https://github.com/ripienaar/puppet-concat Indeed, templates and Concat, either individually or in combination, are great tools for managing files, including where responsibility for different pieces of the file is spread across multiple classes. Unfortunately, none of that is really analogous to Stdlib::File_line, which manages *just* one line in a file, without managing the rest of the file's content. That's a pretty strange thing to do in the Puppet scheme of things, actually, but I suppose it can be useful. I am not aware of any existing, publicly available module providing a type that manages blocks of lines in a manner analogous to Stdlib::File_line. There are several possible approaches that might work instead, depending on the details of the problem, among them: - Manage the whole file (best, if it is feasible). Templates and/or Concat fit right into this. - Put everything on one line and manage it via Stdlib::File_line. That assumes the line breaks are optional (or can be replaced with something else), which is often true, but not always. - Put the managed content in a separate, wholly-managed file, and include it into the target via a target-specific inclusion feature. For instance, some configuration file languages have an 'include' statement that interpolates external files (much like the C preprocessor's #include directive). Better, some programs automatically read all files from a given directory. If none of those are suitable then it's a very unusual case; the best available option may then be to build what you need yourself. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Can anyone recommend a module with a resource managing a block of lines in a file?
On Sat, May 4, 2013 at 7:25 PM, Schofield dbschofi...@gmail.com wrote: I'm hoping a commonly used module that provides a resource for managing multiple contiguous lines in a file already exists and someone can point me to it. I want something like the file_line type in the puppet labs stdlib module but have it check multiple lines instead of just one. This feels like it would be a natural fit to be modeled in augeas (unless I misunderstand your requirements), which is designed for exactly this kind of line by line control of files. For an example you can look at https://forge.puppetlabs.com/domcleal/augeasproviders for some providers Dominic has written. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Practices: what _not_ to manage with Puppet?
On Sun, May 5, 2013 at 2:11 PM, Larry Fast lfast1...@gmail.com wrote:
What about the larger processes involved in incremental updates? Eg.
sequencing your updates so that the service keeps running. I'm considering
using Jenkins to orchestrate sequencial activity.
Coming from an ISConf background, I'd do it makefile-style.
Have actions that indicate completion by touching an empty file, and
tell puppet about it with a creates.
exec { /usr/local/puppetactions/frambulant-upgrade-v1-v2:
...
creates = '/var/lib/puppetactions/frambulant-upgrade-v1-v2'}
}
exec { /usr/local/puppetactions/frambulant-upgrade-v2-v3:
...
requires = Exec['/usr/local/puppetactions/frambulant-upgrade-v1-v2']
creates = '/var/lib/puppetactions/frambulant-upgrade-v2-v3'}
}
Haven't actually used this yet, but my reading of
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/ssn6t2B8us0
is that it would work...
TBH, I am not familiar with Jenkins, perhaps it does something else?
m
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Practices: what _not_ to manage with Puppet?
On Mon, May 6, 2013 at 8:49 AM, Bernardo Costa bf...@ig.com.br wrote: Well, I'll tell you that for now some kind of configuration is difficult to be done with puppet. At least I couldn't find a way to do it. Ex: controlling a /etc/passwd file but partially with a libnss compat syntax. This means entries of local users are no controlled but entries beginning with a '+' are. As I couldn't find a way to do it, for now it is not being controlled by puppet. Interesting -- that sounds like something that Puppet's user/useradd.rb could be taught about? If /sbin/useradd has support for it, I guess it should be a reasonable patch. If not, that's a whole another kettle of fish... I guess what I mean to say is: if Puppet had support for that case, you'd use it. There aren't fundamental or practical reasons no to. Is that correct? cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Can anyone recommend a module with a resource managing a block of lines in a file?
Indeed, templates and Concat, either individually or in combination, are great tools for managing files, including where responsibility for different pieces of the file is spread across multiple classes. This is exactly my situation. I need multiple other modules to contribute multiple lines to the file. Unfortunately, none of that is really analogous to Stdlib::File_line, which manages *just* one line in a file, without managing the rest of the file's content. That's a pretty strange thing to do in the Puppet scheme of things, actually, but I suppose it can be useful. I am not aware of any existing, publicly available module providing a type that manages blocks of lines in a manner analogous to Stdlib::File_line. There are several possible approaches that might work instead, depending on the details of the problem, among them: - Manage the whole file (best, if it is feasible). Templates and/or Concat fit right into this. I would like to use templates if possible but what I have not figured out yet is how to provide the lines from different modules during the catalog compile. Is it possible to send the lines from multiple modules to another and guarantee that the module managing the file has received all the lines? My understanding is that puppet does not guarantee ordering during the catalog compile. - Put everything on one line and manage it via Stdlib::File_line. That assumes the line breaks are optional (or can be replaced with something else), which is often true, but not always. - Put the managed content in a separate, wholly-managed file, and include it into the target via a target-specific inclusion feature. For instance, some configuration file languages have an 'include' statement that interpolates external files (much like the C preprocessor's #include directive). Better, some programs automatically read all files from a given directory. If none of those are suitable then it's a very unusual case; the best available option may then be to build what you need yourself. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] New to hiera
On Sunday, May 5, 2013 8:43:52 PM UTC-5, Josh wrote: Thanks for the replies! Although it's a bit tardy, I'd like to add a word or two here. First, I think it's a mischaracterization to say heira is the recommended way to do things now. Certainly, hiera is the favored interface with external data, and I have said before that hiera finally makes parameterized classes usable. That's not at all the same as hiera being recommended for *every*thing, however. You should not feel that hiera is being imposed on you. Its integration with the Puppet core is a big advance -- the most significant in Puppet 3 -- but to the extent that you already have a manifest set that works in 2.7 without hiera, you have no particular need to convert to using hiera. While I don't like the idea of reaching in to a class to set its variables, Do you mean to *get* its variables? Puppet variables can be set only in the scope to which they belong, and even then only once. It is not possible to reach in to a class to set its variables. On the other hand, a class can reach *out* to obtain values for its variables from an external source. Prevailing Puppet wisdom holds that it is good practice to separate data from classes. given the design flaws in Puppet with parameterized classes, Although I have never been a fan of parameterized classes, with Puppet 3 I no longer attribute the related flaws to parameterized classes themselves, but rather to the parameterized-class declaration syntax, and somewhat to the intentional blurring of the distinction between classes and resources. It's not a particular problem to single out certain variables that characterize the allowed variation in the state described by a given class -- i.e. parameters -- but it is a *fundamental* problem to bind data to parameters in a manner that depends on parse order. Now that there are alternatives to doing the latter, those are separable issues. I devote verbiage to this issue because the word flaw suggests something that can be fixed, but although class parameterization is basically ok (if overrated), the problems with binding data to classes via unrestricted DSL statements (parameterized-style class declarations) are not fixable. That does not reflect a design flaw so much as the nature of the problem. I agree that this is a strength of Heira (so far, the only one, IMHO). Maybe this irks me because I'm also a developer who started with C++. This is actually a hard place from which to come to Puppet. Puppet DSL uses some OO terms and has syntax and structure reminiscent of some OO languages, but it is essential to understand that it is NOT object-oriented in any but the most basic sense. Your developer instincts will send you the wrong signals when you see the words class or inherit, for example. Coming from C/C++ may be especially hard, because include means something radically different in Puppet than in the C world, and define and defined types are very different beasts than C preprocessor macros. Also, the overall mindset attending development in imperative languages is just plain wrong for writing Puppet manifests. C++ (for example) focuses on actions, whereas Puppet DSL is almost entirely about state. Imperative programmers are typically inclined to ask the wrong question: How do I make Puppet do foo?. The correct question is usually How do I model foo-result in Puppet? If you've overcome these issues then I offer my congratulations to you. I looked for docs and didn't find much beyond random blog posts, there are no docs, really... I did read that article. Yes, this a significant weakness for hiera. I am sympathetic to your dissatisfaction there. I'm obviously a stalker. My (senior) co-worker that I'm training on Puppet is very much a pouncer. On Friday I had to say no you actually need to read what it says when trying to get him to use source instead of content (file type). He couldn't copy and paste, oh noes! I understand, though. I read a couple of the articles linked from that one, too, and there are lots of problems with them, and with the example Ashley gave (which the articles mention also). The NTP argument is pretty weak, IMHO. I don't think it's a great NTP module, I guess (I don't use it). =P No offense. =) I think the premise of supporting a new distro or OS (there is more than Linux out there, you know) with just variable flips almost silly. It practically requires modifying everything that will use that new OS. If all you do is flip a variable value, the module probably isn't very comprehensive. I almost always have functional differences for different OSes, like deploying an option file for a port, using .d files for some OSes and not for others, different templates, etc., not just a different package name. You're right, or course, that in many cases the differences from one OS to another requires more than
Re: [Puppet Users] Retrieve scoped resource defaults from class method in custom type
On Sunday, May 5, 2013 2:23:25 PM UTC-5, Ryan R. Uber wrote: Hi Stefan, My apologies that I did not get back sooner. What you are suggesting yields the same results I was seeing before. Let me try to explain better: I think Stefan understood the question. He advised you on the appropriate interface for a resource type to use for adding generated resources to the catalog, but he was clearly uncertain about whether using that approach (which you should do regardless) would be sufficient to resolve your issue. I think the final answer is probably that the Puppet API does not provide a mechanism for what you're asking. It's certainly good that Puppet doesn't automatically exhibit the behavior you describe, but I don't think it provides even an optional way to obtain the defaults. If it did, however, then probably it would be associated with a scope object, since resource defaults are (dynamic) scope-dependent. Can you implement your resource type as a defined type? That would give you resource defaults automatically. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] New to hiera
I'm curious to your opinion on point # 3, are you talking about OS
packages or your organizations app version? If the latter, I was thinking
of using hiera, maybe with a backend other than yaml such as redis, to
store the version of the app, that way like you said it could be used in
deploy pipeline. Why wouldn't you want to do this?
Drew
Hi Drew,
I'm using a yaml backend so I can't speak about other options. So here's my
disertation on why I (mostly) don't want version numbers in hiera. In my
world view, our puppet code is just another component of our system. When
I talk about our pipeline, I'm refering to deploying a version of our
service into an environment. At the highest level, the service version
defines the version of all components - including puppet code. BTW, it's
not a big flat table, just the tip of the dependency tree.
I get my religion from Continuous Delivery (Jez Humble, David Farley) and I
can only hope that I'm not misreading it. Paraphrasing: You can break your
service much faster with a configuration change than with a code change in
one applications. So configuration should be version controlled.
The direction I'm headed is to manage top level version control outside of
our puppet code - with one caveate. We also have {%fqdn} as the first
entry in our hiera tree and the ability to override the version setting via
hiera. But it comes with the following warning:
# FQDN should only be used for temporary overrides.
Cheers,
Larry
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppermaster certificate expired
Hello, We've been running puppet for 5 years until the last week when the certificate on the puppet server is expired. We were looking for a procedure describing how to create a new server certificate without a need to reconfigure certificates on puppet clients (about 100 servers) but we couldn't find anything regarding this issue within puppet's documentation. Is there any best practice guidance to easily fix the problem when puppet master certificate is expired ? Thank you Tomas -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Version Controlling Puppet Configs with svn
That's correct, my concern is permissions/ownership changes inside /etc/puppet on the master after doing commits/check-outs, especially when new manifests are added on clients, outside of the master, then committed to the repo and updated onto the master. Our master currently has mixed ownership between both root and pe-puppet user. I will go with the approach of using the pe-puppet user on the master. On Monday, May 6, 2013 5:43:20 AM UTC-7, Bernardo Costa wrote: I suppose your concerns are about the check-outs of the svn repo on the puppet root direcctory, not about permissions and ownership inside the repo. Once you do svn co command as your user (not recommended), the new files will be created having being owned by you. It might fail if you user does not have permission tho create or modify these files inside the puppet tree source file. The best thing to do is run the svn co command as user puppet but you'll need to set its password or a sudo set of commands. Em domingo, 5 de maio de 2013 00h58min18s UTC-3, P Cornellio escreveu: Hi, I an in the process of putting my Puppet Master configs into version control using SVN. I'm concerned about file permission and ownership changes as a result of this. SVN does not store permissions. How does one safely use SVN with puppet configs? Cheers, Pete -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Feedback on module pattern?
I've been having to write (and modify) a lot of modules lately, and I've so far moved to the following pattern. I'd appreciate comments and feedback about my approach, particularly in light of the changes to name scoping (all my modules are currently deployed under 2.7). 1. mod::defaults (defaults.pp) - does *not* inherit from anywhere - 'include mod::settings' - references module variables with $mod::settings::varname 2. mod::base (base.pp) - 'inherits mod::defaults' - 'include mod' - 'include mod::settings' - any other things which apply to all classes in the module 3. mod::settings (settings.pp) - does *not* inherit from anywhere - has responsibility for resolving and normalising any global or mod() class variables into sane values 4. mod (init.pp) - 'inherits mod::defaults' - 'include mod::settings' - imports all $mod::settings::varname definitions into the $mod namespace - if it's a multi-function module (*i.e.*, classes may be selectively called out for use), this is all it does. - if it's a single-purpose module, the rest of its work can go here -- or in other classes it includes 5. all other classes 1. 'inherits mod::defaults' 2. 'include mod::base' 3. does whatever else it's suppposed to do. The ideas I'm working from are to abstract all the parameter selectors and such into one class, resource declaration defaults into another, and the module top-level namespace and every-class-needs-this stuff into a third. Does this make sense, or is it completely lame? Or are there better patterns (that don't require hiera nor puppetdb) I should consider? Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Having trouble with facter - invalid argument
I'm trying to install Puppet on a Fedora 17 box. The puppet agent --test command fails with this error message: Could not retrieve virtual: Invalid argument - /sys/firmware/dmi/entries/1-0/raw I get the same error message if I type the command facter virtual. This box is a physical machine. It does run KVM so that I can create virtual CentOS servers. Thanks, Charlie -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] facter's zpool_version errors using zfsonlinux
Has anyone run into an issue with zfsonlinux = 0.6.1 failing to work with the Facter zpool_version fact? I get the following error Could not retrieve zfs_version: undefined method `captures' for nil:NilClass which a bug report [1] indicates was fixed. I'm curious if it's a real issue. I have a code change to contribute that has a seperate means of checking zpool_version using confine :kernel = Linux. Should this be a new bug or attached to the other recent bug [1] ? Ran into with puppet-3.1.1 and facter-1.7.0 I believe the underlying problem is that the zpool upgrade -v in zfsonlinux does not output the version number anymore. Using a basic dmesg | grep 'ZFS:' with the same captures line seems to work. I uploaded my module [2] with the proposed facter fact addition if someone would like to confirm this. I have only confirmed in vagrant tests, haven't pushed to my Puppet master yet, but I saw the symptoms on my live systems. Thanks - Trey [1] - http://projects.puppetlabs.com/issues/17794 [2] - https://github.com/treydock/puppet-zfsonlinux -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Feedback on module pattern?
Hi Ken,
I'm not sure I fully understood the purpose of each class, and until then
I'm not pointing out issues. But if my interpretation is correct then you
may get something useful from this other pattern:
# it's probaby your mod::defaults and mod::settings together
class mod::params {
$setting1 = 1
$setting2 = 'a'
}
# entry point
class mod(
$setting1 = $mod::params::setting1,
$setting2 = $mod::params::setting2
) {
class {'mod::install': } -
class {'mod::config':} ~
class {'mod::service':} -
Class['mod']
}
# the classes below reference parameters
# as $mod::setting1
class mod::install {
}
class mod::config {
}
class mod::service {
}
this can be expanded to more than one entry point.
Hope that helps.
El lunes, 6 de mayo de 2013 12:25:30 UTC-5, Ken Coar escribió:
I've been having to write (and modify) a lot of modules lately, and I've
so far moved to the following pattern. I'd appreciate comments and
feedback about my approach, particularly in light of the changes to name
scoping (all my modules are currently deployed under 2.7).
1. mod::defaults (defaults.pp)
- does *not* inherit from anywhere
- 'include mod::settings'
- references module variables with $mod::settings::varname
2. mod::base (base.pp)
- 'inherits mod::defaults'
- 'include mod'
- 'include mod::settings'
- any other things which apply to all classes in the module
3. mod::settings (settings.pp)
- does *not* inherit from anywhere
- has responsibility for resolving and normalising any global or
mod() class variables into sane values
4. mod (init.pp)
- 'inherits mod::defaults'
- 'include mod::settings'
- imports all $mod::settings::varname definitions into the $mod
namespace
- if it's a multi-function module (*i.e.*, classes may be
selectively called out for use), this is all it does.
- if it's a single-purpose module, the rest of its work can go here
-- or in other classes it includes
5. all other classes
1. 'inherits mod::defaults'
2. 'include mod::base'
3. does whatever else it's suppposed to do.
The ideas I'm working from are to abstract all the parameter selectors and
such into one class, resource declaration defaults into another, and the
module top-level namespace and every-class-needs-this stuff into a third.
Does this make sense, or is it completely lame? Or are there better
patterns (that don't require hiera nor puppetdb) I should consider?
Thanks!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet Windows - Mapped Network Drive and Service Account
I found a resolution! Modify the NTFS and Share permissions: - myDomain\Domain Computers = read/execute After the domain join, the computer's local system account has access to the mapped drive. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Having trouble with facter - invalid argument
On Mon, 6 May 2013 10:26:38 -0700 (PDT) Charlie Brune goo...@bruneworld.com wrote: I'm trying to install Puppet on a Fedora 17 box. The puppet agent --test command fails with this error message: Could not retrieve virtual: Invalid argument - /sys/firmware/dmi/entries/1-0/raw I get the same error message if I type the command facter virtual. can you please provide the output of facter -v (this should return the version you are using) and facter --debug --trace virtual When running the last command, you'll hopefully see a strack trace so we can see where the error actually happens. -Stefan -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] What do YOU do to catch undefined variables
On 3 May 2013 06:43, Larry Fast lfast1...@gmail.com wrote: I'm still a puppet newbie and these days I'm struggling with undefined variables. At least once a week I hit an error message like this: Error: Failed to apply catalog: '' is not qualified and no path was specified. Please qualify the command or specify a path. IMO, the core issue is that Puppet has no mechanism for reporting read attempts on undefined variables. So my question to the community is, what do YOU do to catch undefined variables? If anyone has a first class solution I'd love to hear it. But I'm also happy to consider ANY means to detect undefined variables. I may resort to explicitly listing all my variables and checking them with a custom ruby function. I use vim with vim-puppet (and a bunch of other vim plugins). It does syntax highlighting and does syntax and a few other check on saving a file and lets you know if something is amiss. I tried Gepetto but I can't us that over an ssh connection to a server if I need to. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Announce: PuppetDB 1.3.0 Available
PuppetDB 1.3.0 is now available for download! This is a backward compatible feature release of PuppetDB. = ## Downloads ## = Available in native package format at: http://yum.puppetlabs.com and http://apt.puppetlabs.com Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ # Documentation (including how to install): http://docs.puppetlabs.com/puppetdb/1.http://docs.puppetlabs.com/puppetdb/1.2 3 # Issues can be filed at: http://projects.puppetlabs.com/projects/puppetdb/issues # See our development board on Trello: http://links.puppetlabs.com/puppetdb-trello ## PuppetDB 1.3.0 Release Notes ## Many thanks to following people who contributed patches to this release: * Branan Purvine-Riley * Chris Price * Deepak Giridharagopal * Ken Barber * Matthaus Owens * Moses Mendoza * Nick Fagerlund * Nick Lewis Notable features: * Report queries The query endpoint `experimental/event` has been augmented to support a much more interesting set of queries against report data. You can now query for events by status (e.g. `success`, `failed`, `noop`), timestamp ranges, resource types/titles/property name, etc. This should make the report storage feature of PuppetDB *much* more valuable! * Import/export of PuppetDB reports PuppetDB 1.2 added the command-line tools `puppetdb-export` and `puppetdb-import`, which are useful for migrating catalog data between PuppetDB databases or instances. In PuppetDB 1.3, these tools now support importing and exporting report data in addition to catalog data. Bug fixes: * `puppetdb-ssl-setup` is now smarter about not overwriting keystore settings in `jetty.ini` during upgrades * Add database index to `status` field for events to improve query performance * Fix `telnet` protocol support for embedded nrepl * Upgrade to newer version of nrepl * Improvements to developer experience (remove dependency on `rake` for building/running clojure code) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Support for transactions
From all the reading I have done, I have come to the conclusion that 'transaction' support is not offered in Puppet, in any of the predefined language constructs (Specifically speaking of package). Our client has a request that if one package declaration fails, all other package declarations that were successful be rolled back, and the catalog run immediately stop afterwards. From what I can tell, the best approach to this is to run the puppet agent with '--noop' prior to the actual run and check the return code. If it is higher than 2, we have a potential issue. Does this sound correct? Or is there some puppet magic recipe I am missing? Thanks! Birch -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Feedback on module pattern?
This looks great. Some constructive criticism: I think “defaults and “settings” are redundant. Use one. I kind of like the term “params”, but they all do the same thing. On May 6, 2013, at 1:25 PM, Ken Coar wrote: I've been having to write (and modify) a lot of modules lately, and I've so far moved to the following pattern. I'd appreciate comments and feedback about my approach, particularly in light of the changes to name scoping (all my modules are currently deployed under 2.7). mod::defaults (defaults.pp) does not inherit from anywhere 'include mod::settings' references module variables with $mod::settings::varname mod::base (base.pp) 'inherits mod::defaults' 'include mod' 'include mod::settings' any other things which apply to all classes in the module mod::settings (settings.pp) does not inherit from anywhere has responsibility for resolving and normalising any global or mod() class variables into sane values mod (init.pp) 'inherits mod::defaults' 'include mod::settings' imports all $mod::settings::varname definitions into the $mod namespace if it's a multi-function module (i.e., classes may be selectively called out for use), this is all it does. if it's a single-purpose module, the rest of its work can go here -- or in other classes it includes all other classes 'inherits mod::defaults' 'include mod::base' does whatever else it's suppposed to do. The ideas I'm working from are to abstract all the parameter selectors and such into one class, resource declaration defaults into another, and the module top-level namespace and every-class-needs-this stuff into a third. Does this make sense, or is it completely lame? Or are there better patterns (that don't require hiera nor puppetdb) I should consider? Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] hiera not using non-root user custom fact
Hi,
Before I begin, my environment consists of a standard master/client config with
the exception that all my clients run under a non-root user. I have to use
non-root so I can't simply restart under root to fix the problem.
Master - 3.1.1
Client - 2.7.17
using mostly the hiera() function in my classes.
problem:
I have run into an issue today where my custom fact is not being passed to
hiera in order to determine which hiera file to use (see hierarchy). The
custom fact is definitely defined what it should be but its almost as if it has
a differently scope then say a root level custom fact. Because of this hiera
data is coming up undefined which causes my classes to fail.
$myvar = hiera('var-name') -- should use custom_env and custom_release to
help determine where the variable is defined in hiera.
Are custom facts from non root users simply not relayed to hiera?
:hierarchy:
- nodes/%{::fqdn}
- releases/%{custom_release}
- env/%{custom_env}
- common
I have put a bandaid fix in for now which sets these variables via top scope
assignment in one of my classes and allows me to control everything from hiera
instead of using custom facts. However, I am not sure if this follows good
puppet coding practices when using hiera, since I am using hiera to feed hiera.
I don't want to have to define these variables for every node.
bandaid fix:
# this is a top scope variable that is currently a hack to fix an unknown bug
with hiera and local puppet facts
$custom_env = hiera('custom_env') -- defined under nodes/nodename
$custom_release = hiera('custom_release') -- defined under nodes/nodename
class roles::specialapp(
)
{
include specialapp_profile
}
If this is a new bug, I'll be happen to file a ticket.
Thanks,
Corey Osman
co...@logicminds.biz
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Feedback on module pattern?
Hi Ken, I'm happy to give my $.02, FWIW. I've found immense benefit from the overall paradigm described in Craig Dunn's blog post here: http://www.craigdunn.org/2012/05/239/ That paradigm, combined with modules which have all of their variables placed as module::variable_name parameters which default to module::params::variable_name allows for much flexibility: - easy unit test creation. (avoiding trying to get hiera to work with unit tests made this incredibly attractive to us) - clear delineation between 'do-stuff' modules and 'implementation of the do-stuff module in my environment' profiles. This makes the 'do-stuff' modules more re-usable and generally communally consumable, as there are as few as possible environment-specific bits in the 'do-stuff' modules. Depending on the environment, this can also serve as a line in the sand as to which modules can be shared with the world and which contain secret sauce. This also has the added benefit of creating tiers of complication. You can allow your more junior people to orchestrate role modules onto servers, and provision servers. You can have your intermediate admins write, or improve profile modules. A select few can work on your do-stuff modules and help fill out other needs as they arise. This, again, is just my $.02. I'm sure there are many others whose opinions are equally as interesting and may contain more relevant suggestions for your specific implementation. On Mon, May 6, 2013 at 8:22 PM, Dan White y...@comcast.net wrote: This looks great. Some constructive criticism: I think “defaults and “settings” are redundant. Use one. I kind of like the term “params”, but they all do the same thing. On May 6, 2013, at 1:25 PM, Ken Coar wrote: I've been having to write (and modify) a lot of modules lately, and I've so far moved to the following pattern. I'd appreciate comments and feedback about my approach, particularly in light of the changes to name scoping (all my modules are currently deployed under 2.7). 1. mod::defaults (defaults.pp) - does *not* inherit from anywhere - 'include mod::settings' - references module variables with $mod::settings::varname 2. mod::base (base.pp) - 'inherits mod::defaults' - 'include mod' - 'include mod::settings' - any other things which apply to all classes in the module 3. mod::settings (settings.pp) - does *not* inherit from anywhere - has responsibility for resolving and normalising any global or mod() class variables into sane values 4. mod (init.pp) - 'inherits mod::defaults' - 'include mod::settings' - imports all $mod::settings::varname definitions into the $mod namespace - if it's a multi-function module (*i.e.*, classes may be selectively called out for use), this is all it does. - if it's a single-purpose module, the rest of its work can go here -- or in other classes it includes 5. all other classes 1. 'inherits mod::defaults' 2. 'include mod::base' 3. does whatever else it's suppposed to do. The ideas I'm working from are to abstract all the parameter selectors and such into one class, resource declaration defaults into another, and the module top-level namespace and every-class-needs-this stuff into a third. Does this make sense, or is it completely lame? Or are there better patterns (that don't require hiera nor puppetdb) I should consider? Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Fedora 16 leaving yum.puppetlabs.com
As previously announced, Fedora 16 has now been removed from our yum repository as it has reached end of life. On Mon, Apr 15, 2013 at 3:48 PM, Matthaus Owens matth...@puppetlabs.com wrote: Fedora 16 reached end of life on 2013-02-12 [1], so we are no longer building new packages for it and will remove it from our yum repository on Monday, May 6. [1] - https://lists.fedoraproject.org/pipermail/announce/2013-February/003144.html -- Matthaus Owens Release Manager, Puppet Labs Join us at PuppetConf 2013, August 22-23 in San Francisco - http://bit.ly/pupconf13 Register now and take advantage of the Early Bird discount - save 25%! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
