[Puppet Users] Re: How to use Agent on localized Windows?
https://lh5.googleusercontent.com/-aRLPbc_OYbA/UQY4w9ivc6I/ACU/nqH8b5IRbgI/s1600/puppet+3.1b2.png
Puppet client 3.1b2 write other message. It works with US-ASCII only.
пятница, 21 декабря 2012 г., 14:57:50 UTC+4 пользователь Евгений Верещагин
написал:
I try configure Puppet for manage Windows. My OS is localized, all system
users and paths are renamed. If I write some russian text, puppet agent
can't work correctly. For example, if I create user:
user { 'Тест2':
comment = 'Test user2 comment',
password = 'pass',
}
I have bad name of user (in attach). This problem appears because Puppet
use UTF, bat Windows cmd.exe use 866-codepage for Russian. I try add *chcp
65001* command to puppet bat-files, but it did not help.
I try write manifest in 866-codepage, but Puppet Agent crash on startup.
My platforms:
Server 3.0.1 on Debian Wheezy.
Agent 3.0.1 on Windows 7 Ultimate, Russian 64-bit.
--
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.
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] pocco - a puppet manifest documentation experiment
On Friday, 19 October 2012 20:11:51 UTC+2, Nan Liu wrote: On Fri, Oct 19, 2012 at 11:09 AM, Joe Topjian joe.t...@cybera.cajavascript: wrote: Hi Nan, Like everyone else, I think this is great. Run pocco against a modules directory: pocco /etc/puppet/modules/modulename Just a quick comment: Isn't pocco the name of the Python *occo? (http://fitzgen.github.com/pocco/) should the name be changed to differentiate? Ah, didn't realize that, ppocco =), any other suggestions? pucco? :) -- 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. 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] Req setup guide
Hello Guys, Can enyone provide me a step by step setup guide of puppet on rhel6.2 thanks in advanced. -- 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] Puppet // Puppet Dashboard // PuppetDB
Hi I have a frustrating problem with puppet.. I have (had) it all working, I'd gotten puppet-dashboard working and everything was fine :) I then thought I'd try to get puppetDB going so I can use the inventory facilities within puppet dashboard. It's working, sort of. If I click on a node I can see it's inventory, but I'm not getting any new reports - all the reports I see are from before I installed puppetDB the puppetDB log seems to indicate that it's receiving data (i.e. lots of 'store report', 'replace facts' etc), but puppet dashboard isn't reading them. I'm sure I've missed something small in the config somewhere - can anyone point me where I should look? Thanks, in advance... -- 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. 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] Puppet // Puppet Dashboard // PuppetDB
Puppet dashboard doesn't use the puppetdb reports (yet at least), so to get reports into puppet dashboard you need to use the http report handler and set reporturl to point to your puppet dashboard server. -- Erik Dalén On Monday 28 January 2013 at 15:20, Tony McMahon wrote: Hi I have a frustrating problem with puppet.. I have (had) it all working, I'd gotten puppet-dashboard working and everything was fine :) I then thought I'd try to get puppetDB going so I can use the inventory facilities within puppet dashboard. It's working, sort of. If I click on a node I can see it's inventory, but I'm not getting any new reports - all the reports I see are from before I installed puppetDB the puppetDB log seems to indicate that it's receiving data (i.e. lots of 'store report', 'replace facts' etc), but puppet dashboard isn't reading them. I'm sure I've missed something small in the config somewhere - can anyone point me where I should look? Thanks, in advance... -- 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 (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users+unsubscr...@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.
Re: [Puppet Users] Re: Dynamic yum.conf 'exclude' line
On Friday, January 25, 2013 4:05:37 PM UTC-6, Gonzalo wrote: On Sat, Jan 26, 2013 at 1:38 AM, jcbollinger john.bo...@stjude.orgjavascript: wrote: Puppet's architecture does not lend itself to constructing values iteratively, and what Hiera brings to the table in that area does not apply to the scenario you describe. There are a couple of ways you might be able to work around Puppet's constraints there, but before you go that way I would suggest that you consider alternative strategies. Let's start with why you want to add package exclusions to yum.conf via multiple modules. I have some ideas of why you might be trying to implement such a design, but I'd prefer to avoid guessing. Hi John, Thanks for your reply. To be honest, I think in this particular case it's more about trying to work out how to solve this type of problem, perhaps not necessarily useful with this exclude line issue. One hypothetical example might be constructing a users= line for some config file and I want to set users from various modules to construct the line. As I said, Puppet's architecture does not lend itself to that kind of thing. In particular, variables and resource properties can be assigned values only once each. Moreover, it is pretty much always a mistake for manifest sets to attempt introspection, as this introduces unneeded extra sensitivity to manifest parse order. Instead, one generally needs to step back and take a different approach. One such approach might be to build up your data in a custom external node classifier (ENC), which provides it to your classes via either a global Puppet variable or a class parameter. Another approach is for modules to declare independent resources instead of collaborating on a single resource. The Concat add-on module, for example, provides a way to implement that for files. You could, in principle, implement similar facilities to serve other purposes. Or you may find that you don't actually need quite the degree of flexibility you describe after all. For this exclude line question, I have a class that many nodes include and they all need to exclude one particular RPM to ensure a yum update never upgrades it. These same servers include another class, which also have a package to be excluded. Do you have any ideas on how to solve this type of problem? For packages in particular, you have additional options: 1. In your Package declarations, you can use ensure = 'present' or even ensure = 'package-version' instead of ensure = 'latest'. That won't prevent a manual package update, but it will prevent Puppet from performing unwanted package updates. The variation where you specify a package version may even get Puppet to revert unwanted manual updates. 2. You really ought to take control of your package repositories. Creating and curating local repositories not only ensures access and reduces demands on your network connection to the outside world, but it also allows you to exercise complete control over what packages are available for installation / update. Depending on your package management system, local repositories may confer additional benefits. For example, on 'yum'-based systems you might consider looking at the yum-priorities and yum-protectbase plugins. 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. 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] testing puppet manifests
The information I can find is somewhat spotty.. but is there a good way to test puppet manifests. It seems that using 'puppet apply --noop' only really tests the syntax. I am looking for more functional tests for things like templates before they go into a prod environment. Right now the way I have been testing is to put some test code on the puppetmaster and watch the logs very closely. this is not ideal, any suggestions? -- 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. 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] How to increase performance of managed directories?
On Thursday, January 10, 2013 1:57:34 AM UTC-5, Pete wrote: I used to manage a few directories recursively and it was very slow and cumbersome. I just manage the directories themselves if i need to and the files individually. It makes it a bit more complex initially but you get fine grained control over things and it's so much faster. If you really need to manage a directory recursively and there is no other way I recommend using your preferred version control system. If you want to do that easily with puppet then puppetlabs/vcsrepo on the forge looks like the nicest way of doing it. Is there a simple way to recursively pull directories down from the puppet master if they don't exist, but if the root directory does exist don't bother recursively checking them? -- 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. 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] Puppet variable in site not accessible from class
Hi, I am having trouble trying to auto configure network on a client :
Her are the important content :
Site.pp :
import classes/client.pp
import classes/server.pp
import classes/service1.pp
import classes/default-company.pp
...
node 'puppet-test-ubuntu.sub.domain.com' inherits service1 {
$dns1 = 172.20.10.73
$dns2 = 192.168.1.22
$dns3 = 172.20.10.14
$myip = 172.20.88.86
$mydomain = domain.com
notify { site :
message = $myip - $mydomain - $dns1
}
}
classes/service1.pp
node service1 inherits default-company {
include module1
include network
include module3
}
module/network/manifest/init.pp:
class network::install-common {
}
class network::install-Debian {
}
class network::install-RedHat {
}
class network::config-common {
notify { network :
message = $myip - $mydomain - $dns1
}
file { /etc/network/interfaces :
ensure = present,
owner= root,
group= root,
mode = 0644,
#content =
template('/etc/puppet/modules/network/templates/interfaces')
}
file { /etc/resolv.conf :
ensure = present,
owner = root,
group = root,
mode= 0644,
content = template('/etc/puppet/modules/network/templates/resolv.conf')
}
}
class network::config-Debian {
}
class network::config-RedHat {
}
class network::service {
}
class network {
include network::install-common, network::install-$osfamily,
network::config-common, network::config-$osfamily, network::service
}
When I run puppet agent -t on node puppet-test-ubuntu.sub.domain.com, I
got this :
notice: - sub.domain.com -
notice: /Stage[main]/Network::Config-common/Notify[network]/message:
defined 'message' as ' - sub.domain.com - '
notice: 172.20.88.86 - domain.com - 172.20.10.73
notice:
/Stage[main]//Node[puppet-test-ubuntu.unix.parrot.biz]/Notify[site]/message:
defined 'message' as '172.20.88.86 - domain.com - 172.20.10.73'
How should I define the variable to get :
notice: /Stage[main]/Network::Config-common/Notify[network]/message:
defined 'message' as '172.20.88.86 - domain.com - 172.20.10.73' ?
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.
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: define()'s sloooow
On Friday, January 25, 2013 9:29:00 AM UTC-6, asq wrote: W dniu piątek, 25 stycznia 2013 16:07:43 UTC+1 użytkownik jcbollinger napisał: To be clear, it looks like you are talking about counts of defined type * instances*, not counts of distinct defined types. Is that right? yes. it's test::rule() and test::rule_inline() in linked manifest. I am inclined to suspect that the problem is not defined types in general, but rather the specific defined types you are using. Indeed, your data seem to support that inasmuch as inlining definitions doesn't cut your compilation times very much. we're talking about 5m33s and 4m13s difference in compile. this *is* a lot. The version using more defined-type instances has more total resources. The time per resource is very nearly the same. Your compile times certainly will scale with the total number of resources declared. Do not confuse defined types with macros. They are bona fide resource types, functioning like native types in most ways. I can think of several things might cause long compilation times: - evaluating many templates, especially complex ones - making many hiera lookups if your hierarchy definition uses interpolated non-global variables - repetition of anything requiring network access, such as syncing files with a version-control repository, accessing files on a remote file system, or performing name resolutions. - calling generate() a lot That's not an exhaustive list. please check define rule_inline() in linked pp file - it's nothing fancy. Fanciness is not the question. Even very simple manifests can make declarations that are costly to compile. - 3 static files - 1 erb (35 lines with 5 variables substitution and 1 if/else clause) The erb evaluation is probably more costly than everything else about that particular File declaration, combined. Especially so in that it requires (in that particular case) up to four separate probes of the file system just to find the template file. - 1 hiera call I believe hiera caches data to the extent that it can do, but depending on how your hierarchy is defined and how your data are arranged, it could still be that each one of those hiera() calls involves filesystem probes and possibly reading and parsing YAML. That's not particularly cheap even if your data are simple. - 1 exported resource I must have overlooked that, but it's not especially cheap, either, inasmuch as it involves connecting to and querying a DB. It's practically expensive if the underlying DB is not local, as that then would involve network activity. - 4 calls to custom type (firewall) Which are probably cheap(ish), but that's not certain. no generates or other puppetmaster functions, no network stuff, no dns-related stuff or anything i haven't already hashed-out to test if it will affect compile times significantly. Anyway, I think filing a bug now would be premature. It may be that there is a bona fide performance problem, but if so then I don't think it has been pinpointed yet. i filed a bug #18880 anyway, as i sense it might be some design error in puppet - i can't really see why number of define() calls should relate to compile times. as they are not real resources, there should be no reason for them to be included in catalog, which also might relate to apply times. Definition instances certainly are real resources in most ways that matter. In any event, your compilation times even for the inline version of your manifests seem unreasonably high, which is why I suggested that you look at other possible performance drags. In addition to the manifest-specific issues I discussed above, you should also look at how your master is provisioned and loaded. Puppet is a bit of a memory hog, so if the available physical RAM is low then Puppet may perform a lot of expensive swaps between physical and virtual RAM. If the master is sharing hardware with other services (even other masters in, for example, a passenger setup), then contention for the disk subsystem could slow everything, especially if you have SATA (or worse) disks instead of SCSI. There are many other such possibilities. On the other hand, I don't mean to suggest that declaration of defined-type instances is free or cheap. As I said, defined types are not macros, but rather bona fide resource types. Declaring a defined-type instance involves more work than simply making all the declarations that appear in the definition body. 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,
[Puppet Users] Re: hash/class problem
On Friday, January 25, 2013 5:26:13 AM UTC-6, emzvargas wrote:
Hello.
I'm kind of new with puppet and i'mhaving a problem using hashes with
classes or defines.
Here is an example of what im trying to do:
$myhash = { key = some value,
other_key = some other value,
other_ki = other other,
}
class test{
file {/var/tmp/$myhash[key]:
ensure = present,
}
}
class {'test':
}
Result:
Error: Invalid tag /var/tmp/other_keysome other valuekeysome
valueother_kipepe at /etc/puppet/manifests/site.pp:10 on nod
Puppet string interpolation does not recognize references to components of
compound values. Instead, you are getting interpolation of the whole hash
(coerced to a string). Do this instead:
class test{
$value = $myhash['key']
file {/var/tmp/$value:
ensure = present,
}
}
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.
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: About How puppetserver handle reuest from client
On Friday, January 25, 2013 7:16:19 AM UTC-6, sneha...@gmail.com wrote: Hi, I am using puppet from last 2-3 months, I want to know about how puppet internally handles request from puppet client, sequentially or parallel execution as in Puppet Enterprise - Orchestration. Is There ant way of providing facility like orchestration-mcollective in puppet? Can we apply manifest on multiple machine at same instatnce in Open source puppet? The open-source Puppet engine, which is also the heart of Puppet Enterprise, is single-threaded and compiles one catalog at a time. For higher throughput, one generally gangs multiple Puppet instances under the control of a Rack server such as passenger. As I understand it, Puppet Enterprise just packages all that up for convenient installation and configuration, but a lot of sites do the same thing with open-source Puppet. 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.
[Puppet Users] Re: define()'s sloooow
W dniu poniedziałek, 28 stycznia 2013 16:49:38 UTC+1 użytkownik jcbollinger napisał: - 1 erb (35 lines with 5 variables substitution and 1 if/else clause) The erb evaluation is probably more costly than everything else about that particular File declaration, combined. Especially so in that it requires (in that particular case) up to four separate probes of the file system just to find the template file. i replaced this erb with string foo and it showed sub-second differences, not really measurable for 2000 resources. - 1 hiera call I believe hiera caches data to the extent that it can do, but depending on how your hierarchy is defined and how your data are arranged, it could still be that each one of those hiera() calls involves filesystem probes and possibly reading and parsing YAML. That's not particularly cheap even if your data are simple. disabling hiera shaves about 10 seconds on 2000 resources. not a big deal either. - 1 exported resource I must have overlooked that, but it's not especially cheap, either, inasmuch as it involves connecting to and querying a DB. It's practically expensive if the underlying DB is not local, as that then would involve network activity. disabling it shaves another 30 seconds on 2000 resources. nothing spectacular, considering that only adding 200-300 resources will make this time as high again. - 4 calls to custom type (firewall) Which are probably cheap(ish), but that's not certain. yes, hashing them out doesn't help much. In addition to the manifest-specific issues I discussed above, you should also look at how your master is provisioned and loaded. Puppet is a bit of a memory hog, so if the available physical RAM is low then Puppet may perform a lot of expensive swaps between physical and virtual RAM. If the master is sharing hardware with other services (even other masters in, for example, a passenger setup), then contention for the disk subsystem could slow everything, especially if you have SATA (or worse) disks instead of SCSI. There are many other such possibilities. i've tried to bind those problems to i/o but putting manifests on ramdisk doesn't help at all. manifests are still compiling very slow. i know that those times are high. but anyway i can't find a single bit that makes it so. i think puppet is very sensitible to the way its used. when you look at ruby 1.8/1.9 comparisions for the same manifests, you can clearly see that something worrying is happening, as newer ruby should be more optimized, but instead it runs significantly slower. on production we use passenger with no of puppetmaster processes equal to number of threads (and queue of excessive catalog requests on haproxy on front of it). -- 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. 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: define()'s sloooow
W dniu poniedziałek, 28 stycznia 2013 17:04:51 UTC+1 użytkownik asq napisał: on production we use passenger with no of puppetmaster processes equal to number of threads (and queue of excessive catalog requests on haproxy on front of it). i mean - number of cores (8). -- 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. 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: Extending a standard type
On Saturday, January 26, 2013 6:55:57 PM UTC-6, Matthew Pounsett wrote:
I'm trying to extend the standard 'user' type to add maintenance of some
of the contents of a user's home directory, and I'm trying to avoid
creating an entirely new custom type if I can. The approach I'm taking is
to create a site::user defined type which in turns calls the standard user
type.
That's a good and widely-used approach.
I'm having a problem figuring out how to manage the optional parameters.
The most likely path seems to be something like this (simplified for
example):
define site::user (
$comment,
$ensure,
$home,
$name = $title,
Don't do that ($name = $title). Puppet provides it automatically (both the
parameter and the default).
Moreover, I am uncertain whether it is safe anyway to use $title as a
resource default. It certainly *isn't* safe to use explicit resource
properties, regardless of the order in which they are listed.
$password,
) {
user { $title:
comment = $comment,
ensure = $ensure,
home = $home,
name = $name,
password = $password,
}
}
The problem with this, of course, is that the parameters to site::user
aren't optional, and I'd like them to be. I've tried setting their
defaults to null strings, but I get errors about reassigning variables if I
do that.
The usual paradigm is this:
define mymodule::foo ( $param1 = 'NOTSET' ) {
$real_param1 = $param1 ? {
'NOTSET' = some-appropriate-value-maybe-undef,
default = $param1
}
sometype { $name:
param = $real_param1
}
}
Yes, it's a bit clunky, but it works.
Of course, this would be even better.. but doesn't appear to be a valid
syntax in puppet:
define site::user ( $**args ) {
user { $title:
$args
}
}
No, Puppet doesn't have anything like that. The closest would probably be
the create_resources() function, which you can read about in the docs.
This seems to me to be the sort of thing that'd be in a puppet cookbook,
but google hasn't shown me any useful docs or examples for what I'm trying
to do. Does this approach even make sense, or is there a better way?
I'm surprised you didn't find an example like the one above. It appears
all over the place, not least in the archives of this group.
Also, have you read the official Puppet DSL docs (at
http://docs.puppetlabs.com/puppet/3/reference/)? They don't answer your
particular question, but they would have told you about $name, and they
have a lot of other useful information.
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.
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] Referencing a variable from one class in another
I have one module, kibana, that defines a file snippet for the apache module to fulfill (e.g., /etc/https/conf.d/kibana.conf). The apache::params class defines a variable of the path of where this snippet should be placed, $config_d. The snippet uses this variable in its definition. However, it seems that the snippet never resolves the $apache::params::config_d variable, and I'm guessing because the order of instantiation isn't right. I've tried requiring the apache class from the snippet, which seems it would enforce proper ordering, and I've tried inheriting the kibana::apache class from apache::params. The former still doesn't resolve and the latter throws an agent error. What is the proper way for using a variable in one class in another class when manifests/nodes.pp definitions of the classes can't be guaranteed? Here are snippets of the class definitions I'm using: http://pastie.org/5910079 -- 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. 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] testing puppet manifests
The best starting point is probably rspec-puppet. The tutorial is a good starting point and you'll find a growing number of modules available with small test suites. These are good for testing logic based on passed parameters, or template rendering. http://rspec-puppet.com/tutorial/ Gareth On 28 January 2013 14:43, Scott Anderson s...@torand.org wrote: The information I can find is somewhat spotty.. but is there a good way to test puppet manifests. It seems that using 'puppet apply --noop' only really tests the syntax. I am looking for more functional tests for things like templates before they go into a prod environment. Right now the way I have been testing is to put some test code on the puppetmaster and watch the logs very closely. this is not ideal, any suggestions? -- 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. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- 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] Referencing a variable from one class in another
On Mon, 2013-01-28 at 08:24 -0800, Ti Leggett wrote:
I have one module, kibana, that defines a file snippet for the apache
module to fulfill (e.g., /etc/https/conf.d/kibana.conf). The apache::params
class defines a variable of the path of where this snippet should be
placed, $config_d. The snippet uses this variable in its definition.
However, it seems that the snippet never resolves the
$apache::params::config_d variable, and I'm guessing because the order of
instantiation isn't right. I've tried requiring the apache class from the
snippet, which seems it would enforce proper ordering, and I've tried
inheriting the kibana::apache class from apache::params. The former still
doesn't resolve and the latter throws an agent error. What is the proper
way for using a variable in one class in another class when
manifests/nodes.pp definitions of the classes can't be guaranteed?
Here are snippets of the class definitions I'm using:
http://pastie.org/5910079
Variable references like $apache::params::config_d are parse-order
dependant. The class apache::params has to be parsed on the master
before you reference the variable. (Order of application doesn't matter,
so you don't need to use 'require')
The fix is trivial, just add an include apache::params (or even just
include apache) at the top of your kibana::apache class, like so:
# modules/kibana/manifests/apache.pp
class kibana::apache (
$version = $kibana::params::parameters['version'],
) {
include apache::params
@file { $kibana::params::apache_config:
...
However, this conflicts with the class {} style declarations in your
apache/manifests/init.pp file. For best results, you should switch those
to use the include method as well.
--
Calvin Walton calvin.wal...@kepstin.ca
--
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] Referencing a variable from one class in another
On Jan 28, 2013, at 10:56 AM, Calvin Walton calvin.wal...@kepstin.ca wrote:
The fix is trivial, just add an include apache::params (or even just
include apache) at the top of your kibana::apache class, like so:
# modules/kibana/manifests/apache.pp
class kibana::apache (
$version = $kibana::params::parameters['version'],
) {
include apache::params
@file { $kibana::params::apache_config:
...
However, this conflicts with the class {} style declarations in your
apache/manifests/init.pp file. For best results, you should switch those
to use the include method as well.
Thanks for the response.
Can multiple classes include the same class. Let's say I instantiate the apache
class from manifests/nodes.pp which in turns includes apache::params. Can
kibana include apache::params then as well with no conflict. I know you can't
do this with the class {} style declarations. Also, I thought the class {}
style declarations were the preferred way or is that just in the nodes.pp file?
--
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] puppetmaster loads ruby gems which significantly slows it down
as a side check for define()'s slw topic, i've shaved my rvm ruby from all gems (but passenger and gpgme used by hiera) to observe compilation times drop in half. wtf? why is puppet/ruby loading all those gems it doesn't need? i share my rvm ruby with foreman, so i had installed some 60 gems (some in more than one version for testing) just for it. i don't expect that they should be even touched by puppetmaster process. -- 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. 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] Referencing a variable from one class in another
On Mon, 2013-01-28 at 11:00 -0600, Ti Leggett wrote:
On Jan 28, 2013, at 10:56 AM, Calvin Walton calvin.wal...@kepstin.ca wrote:
The fix is trivial, just add an include apache::params (or even just
include apache) at the top of your kibana::apache class, like so:
# modules/kibana/manifests/apache.pp
class kibana::apache (
$version = $kibana::params::parameters['version'],
) {
include apache::params
@file { $kibana::params::apache_config:
...
However, this conflicts with the class {} style declarations in your
apache/manifests/init.pp file. For best results, you should switch those
to use the include method as well.
Thanks for the response.
Can multiple classes include the same class. Let's say I instantiate
the apache class from manifests/nodes.pp which in turns includes
apache::params. Can kibana include apache::params then as well with no
conflict. I know you can't do this with the class {} style
declarations. Also, I thought the class {} style declarations were the
preferred way or is that just in the nodes.pp file?
Yes, with the include syntax, you can include a class multiple times
from different places with no conflicts. It's a no-op if the class is
already included.
The include method is the preferred syntax (in my opinion, but I'm
sure other share it), due to this feature - particularly if you're using
hiera to pull configuration in. The only time you should be using the
class {} syntax is if you need to pass in class parameters and can't use
hiera.
--
Calvin Walton calvin.wal...@kepstin.ca
--
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: Extending a standard type
On Monday, 28 January 2013 11:14:59 UTC-5, jcbollinger wrote:
define site::user (
$comment,
$ensure,
$home,
$name = $title,
Don't do that ($name = $title). Puppet provides it automatically (both
the parameter and the default).
In this case, $name is the login name of the user being created .. it's a
valid parameter of the 'user' resource type. I'm not sure how I'm supposed
to do not use it. I have read the Puppet reference manual.. but not for
puppet 3, since I'm not using that.
Moreover, I am uncertain whether it is safe anyway to use $title as a
resource default. It certainly *isn't* safe to use explicit resource
properties, regardless of the order in which they are listed.
I'n not sure what you mean by that. Using $title as a default is widely
used (see namevar) .. I'm not sure what you mean about explicit resource
properties.
The usual paradigm is this:
define mymodule::foo ( $param1 = 'NOTSET' ) {
$real_param1 = $param1 ? {
'NOTSET' = some-appropriate-value-maybe-undef,
default = $param1
}
sometype { $name:
param = $real_param1
}
}
Yes, it's a bit clunky, but it works.
This is great if I want to set my own defaults, but I don't. The 'user'
resource already has its own way of handling unspecified parameters, and I
don't want to override those unless absolutely necessary. I think the
above would require me to re-implement a bunch of its defaults logic, which
would be especially problematic for things like 'gid'.
No, Puppet doesn't have anything like that. The closest would probably be
the create_resources() function, which you can read about in the docs.
I'll have a look.. maybe there's some way I can make use of it.
I'm surprised you didn't find an example like the one above. It appears
all over the place, not least in the archives of this group.
Also, have you read the official Puppet DSL docs (at
http://docs.puppetlabs.com/puppet/3/reference/)? They don't answer your
particular question, but they would have told you about $name, and they
have a lot of other useful information.
The only occurrence of the string name in the DSL doc at that location is
as a placeholder... and it applies to ruby, not puppet manifests. I don't
see anything there about use of $name inside a puppet class.
--
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.
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] Referencing a variable from one class in another
On Monday, January 28, 2013 5:00:24 PM UTC, Ti Leggett wrote:
Thanks for the response.
Can multiple classes include the same class. Let's say I instantiate the
apache class from manifests/nodes.pp which in turns includes
apache::params. Can kibana include apache::params then as well with no
conflict. I know you can't do this with the class {} style declarations.
Also, I thought the class {} style declarations were the preferred way or
is that just in the nodes.pp file?
Yes, they can. That's the main selling point for the include class
syntax. And you are right, you can't use the class {...} syntax more than
once or you get a duplicate definition error.
However, let me warn you against going overboard with having classes
include other classes from other modules. It can be annoying to track down
where resources coming from for any given node if you've got cross module
inclusion: kibana includes httpd includes mod_ssl includes openssl includes
somethingelse includes ... How did this get on here?
A cleaner way might be to declare cross module relationships using the
Arrow operators:
class kibana::apache {
Class[apache::params] - Class[kibana::apache]
...
}
And then you make a house rule to have all your classes instantiated in
your node definitions:
node woof {
class kibana
class apache::params
}
If apache::params is missing, you'll get an error saying so. It also fits
rather nicely into an ENC if you want to go in that direction now / later.
-Luke
--
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.
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] Referencing a variable from one class in another
On Mon, 2013-01-28 at 09:12 -0800, Luke Bigum wrote:
On Monday, January 28, 2013 5:00:24 PM UTC, Ti Leggett wrote:
However, let me warn you against going overboard with having classes
include other classes from other modules. It can be annoying to track down
where resources coming from for any given node if you've got cross module
inclusion: kibana includes httpd includes mod_ssl includes openssl includes
somethingelse includes ... How did this get on here?
A cleaner way might be to declare cross module relationships using the
Arrow operators:
class kibana::apache {
Class[apache::params] - Class[kibana::apache]
...
}
And then you make a house rule to have all your classes instantiated in
your node definitions:
node woof {
class kibana
class apache::params
}
If apache::params is missing, you'll get an error saying so. It also fits
rather nicely into an ENC if you want to go in that direction now / later.
While this is a good idea in general, it doesn't solve Luke's original
problem. In order to reference a variable $apache::params::something
from inside the kibana::apache class, you need the apache::params class
to be parsed on the puppet master before the kibana::apache class. This
is a parse-time ordering problem, not a run-time ordering problem.
The only way to force parse-time ordering right now is to do a direct
include, unfortunately.
--
Calvin Walton calvin.wal...@kepstin.ca
--
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: Dynamic yum.conf 'exclude' line
Take a look at the yum versionlock plugin. It allows you to lock a
particular package at a given version for situations like this. We use the
following define to manage our locked packages. If I were writing it today
I'd probably use file_line, but it's worked well for us so I've had more
important things to do.
#
# Actions:
# Implements a versionlock define to make version locking easy
#
# Requires:
#
# Sample Usage:
#
# To lock a package version:
# packages::yum::versionlock{ kernel-uek:
# epoch = '(none)',
# version = '2.6.32',
# release = '100.26.2.el5',
# }
#
# To remove a version lock:
# packages::yum::versionlock{ kernel-uek:
# epoch = '(none)',
# version = '2.6.32',
# release = '100.26.2.el5',
# ensure = 'absent',
# }
define packages::yum::versionlock ($epoch,$version,$release,$ensure =
'present',
$version_lock_list =
'/etc/yum/pluginconf.d/versionlock.list') {
include packages::yum
case $ensure {
present: {
exec { yum_add_versionlock_${name}:
command = /bin/echo '${epoch}:${name}-${version}-${release}'
'${version_lock_list}',
unless = /bin/grep -q '${epoch}:${name}-${version}-${release}'
'${version_lock_list}',
require = Package['yum-versionlock'],
} # exec
} # case 'present'
absent: {
exec { yum_del_versionlock_${name}:
command = sed -i -e /'${epoch}:${name}-${version}-${release}'/d
'${version_lock_list}',
onlyif = /bin/grep -q '${epoch}:${name}-${version}-${release}'
'${version_lock_list}',
require = Package['yum-versionlock'],
} # exec
} # case 'absent'
} # case $ensure
} # define
On Mon, Jan 28, 2013 at 6:40 AM, jcbollinger john.bollin...@stjude.orgwrote:
On Friday, January 25, 2013 4:05:37 PM UTC-6, Gonzalo wrote:
On Sat, Jan 26, 2013 at 1:38 AM, jcbollinger john.bo...@stjude.orgwrote:
Puppet's architecture does not lend itself to constructing values
iteratively, and what Hiera brings to the table in that area does not apply
to the scenario you describe. There are a couple of ways you might be able
to work around Puppet's constraints there, but before you go that way I
would suggest that you consider alternative strategies.
Let's start with why you want to add package exclusions to yum.conf via
multiple modules. I have some ideas of why you might be trying to
implement such a design, but I'd prefer to avoid guessing.
Hi John,
Thanks for your reply.
To be honest, I think in this particular case it's more about trying to
work out how to solve this type of problem, perhaps not necessarily useful
with this exclude line issue. One hypothetical example might be
constructing a users= line for some config file and I want to set users
from various modules to construct the line.
As I said, Puppet's architecture does not lend itself to that kind of
thing. In particular, variables and resource properties can be assigned
values only once each. Moreover, it is pretty much always a mistake for
manifest sets to attempt introspection, as this introduces unneeded extra
sensitivity to manifest parse order. Instead, one generally needs to step
back and take a different approach.
One such approach might be to build up your data in a custom external node
classifier (ENC), which provides it to your classes via either a global
Puppet variable or a class parameter.
Another approach is for modules to declare independent resources instead
of collaborating on a single resource. The Concat add-on module, for
example, provides a way to implement that for files. You could, in
principle, implement similar facilities to serve other purposes.
Or you may find that you don't actually need quite the degree of
flexibility you describe after all.
For this exclude line question, I have a class that many nodes include
and they all need to exclude one particular RPM to ensure a yum update
never upgrades it. These same servers include another class, which also
have a package to be excluded. Do you have any ideas on how to solve this
type of problem?
For packages in particular, you have additional options:
1. In your Package declarations, you can use ensure = 'present' or
even ensure = 'package-version' instead of ensure = 'latest'. That
won't prevent a manual package update, but it will prevent Puppet from
performing unwanted package updates. The variation where you specify a
package version may even get Puppet to revert unwanted manual updates.
2. You really ought to take control of your package repositories.
Creating and curating local repositories not only ensures access and
reduces demands on your network connection to the outside world, but it
also allows you to exercise complete control over what packages are
available for installation / update. Depending on your package management
system, local repositories may confer additional benefits. For example, on
Re: [Puppet Users] Puppet Support for Windows
Hi Damian, On Sat, Jan 26, 2013 at 1:12 PM, damian.folw...@gmail.com wrote: Hi All, I am currently looking at using PE to provide our config management (and orchestrated deployment via MCollective) for our app stack. It is currently used to manage the Linux OS estate but not yet for Windows. I'd like to use the same tool so that the people who develop and manage apps on both OS only have a single learning curve and given PE is already used in the organisation that is my first choice. In my initial investigation there are a number of critical functions that currently cannot be managed out the box (or via modules on PuppetForge) which i would have expected from a tool such as this. (I appreciate that Windows support on Puppet is relatively new and that I could create my own modules. However that would mean learning Ruby *and* Puppet, diverting resource away from their main job, and convincing management to allow custom coding something that they'd expect out of the box of such a tool is going to be tricky!). So, are there currently any plans to provide - NTFS file support to allow detailed control of permissions settings and not relying on the very limited POSIX - Windows mapping in the current File resource. (And yes i understand the RAL and reasons behind it, but this is kind of a deal breaker for us for the Windows side of our estate)? This is on our Windows roadmap, filed as https://projects.puppetlabs.com/issues/13249. Recently, the priority has increased as we've been hearing similar comments from other users. With that said, I'm curious what use cases you're looking to solve. Are you looking to specify the complete state of the DACL, e.g. grant permissions to these accounts, deny to these, control inheritance? Or a partial state, e.g. ensure administrators has full control and ignore other ACEs that are present. Or is it a compliance issue, e.g. ensure only administrators can write? Also are you looking to manage DACLs on other securable objects, e.g. registry keys. Also are you looking to manage SACLs? - Setting the user for a Service on Windows? (I know i could probably exec out to sc.exe to achieve this but would like it config managed) This is filed as https://projects.puppetlabs.com/issues/17706. It would be trivial to implement, as we already have the SID resolution code in place, and it would be similar to how we manage the user account for scheduled tasks. And probably not for this forum (but i know PuppetLabs employees are reading)... - Do you have any idea of of when MCollective support in Puppet Enterprise will be provided for Windows. I can't specify when exactly, but this is a high priority for us. The top-level ticket is filed as https://projects.puppetlabs.com/issues/11206. The hard work of getting mcollective running on windows has already been done. The remaining issues are around packaging, updating PE modules to support windows, and better mcollective control of the puppet agent, all of which are straightforward tasks. Josh -- Josh Cooper Developer, Puppet Labs -- 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] All nodes are showing unresponsive
I should note also that the Console determines the time a node last submitted a report based on the agent's timestamp. If your agents' time is out of sync from the master, it is common to see this. On Friday, January 25, 2013 10:47:01 AM UTC-5, Gary Larizza wrote: Mamta, Nodes go 'Unresponsive' in the Puppet Dashboard/Enterprise Console when they haven't submitted a report to the Puppet master in a timely manner. Are you able to get on one of your agents and perform a Puppet run with `puppet agent -t`? Does the Puppet run complete successfully or throw an error? If it completes successfully, does the dashboard status update? On Thu, Jan 24, 2013 at 11:05 PM, Mamta Garg itsmam...@gmail.comjavascript: wrote: Hi, Can anyone please tell me regarding below- I have setup CentOS Linux master with 10 windows agent. Now my all Agents nodes are showing 'Unresponsive' on puppet dashboard. Please tell me how i can make it responsive? -- Thanks and Regards, Mamta Garg -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- Gary Larizza Professional Services Engineer -- 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. 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] Puppet Support for Windows
Hi Josh,
First of all thanks for the quick reply.
The main priorities to make Puppet usable on Windows for us would be:
1 Control complete state of the DACL for grant (we don't use deny).
2 Control inheritance on DACL (at the same time as being able to control
other DACL grant entries for that object).
3 Control inheritance on SACL (we only set this at a higher level).
4 Set user account on Service.
It would also be good to have the following (although don't think it would
be a showstopper for adoption):
5 Control ACL on local SMB shares.
6 Control ACL on registry.
And finally the nice to haves:
7 (Nice to have) Set DACL on parent directory but inherit permissions on
all children when using source param with multiple levels of hierarchy.
8 (Nice to have) Set DACL on parent directory but inherit permissions on
all children when using recurse param.
Off the top of my head (not fully worked out all our requirements with the
devs yet) I don't think we control access to any other types of windows
object (e.g. service)
I did start having a dig in the Puppet code for the file type and all of
the building blocks are already there. I'm not sure how much effort it
would be to write an ntfsfile class but I have started having a play with
writing my own (in my spare time) but I've never written Ruby before so a
reasonable learning curve (not least just to understand the mass of file
and windows provider Puppet code let alone Ruby!). The permission setting
methods are all there (e.g. set_acl and get_acl from security.rb including
the protected parameter that i couldn't see a way of setting anywhere). My
plan was to replace the mode param on file.rb with a dacl param that could
take some form of friendly dacl description. The get_mode and set_mode
methods could then be changed to translate between friendly dacl and real
dacl rather than POSIX mode and dacl.
The friendly DACL would use something like the following to describe each
ACE:
ntfsfile { 'myfile.txt' :
require = file,
dacl = [
['user1', grant, [FULL_CONTROL]],
['user2', grant, [FILE_READ]],
['group1', grant, [FILE_READ, FILE_WRITE,
CHANGE_PERMISSIONS]],
['user3', deny, [FILE_READ, FILE_WRITE, FILE_EXECUTE]]
],
inheritparent = false,
source = 'puppet://modules/something/file.txt',
}
--
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.
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] Invalid resource type anchor.
I noticed that puppet modules installs modules in */etc/puppet/modules*, which is different than where I keep my modules. I added* /etc/puppet/modules *to the* modulepath *in puppet.conf, fixed the problem On Tuesday, October 9, 2012 11:01:55 AM UTC-4, Fran Rodríguez wrote: Thanks Hugh, you are right!! Now it works. On Tuesday, October 9, 2012 12:20:33 PM UTC+2, Hugh Cole-Baker wrote: On Tuesday, October 9, 2012 10:24:53 AM UTC+1, Fran Rodríguez wrote: Yes, it does. This occurs when change apt module for the puppetlabs-apt. Maybe is a issue with environments, im trying to figure out what is happening, and like the log said the module stdlib which provide the anchor type, is not being recognize. I had the same problem, caused by the puppetlabs-stdlib Ruby libraries not being available to the puppet master when it was parsing and compiling the manifests. It's related to bug http://projects.puppetlabs.com/issues/13858 as far as I can tell. The solution was to run puppet agent on the master itself, with pluginsync enabled, such that the required plugins from the puppetlabs-stdlib module get synced onto the master. -- 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. 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: Puppet Dashboard 1.2.21 available [ security release ]
Puppet Dashboard 1.2.21 is now available. This release of Puppet Dashboard addresses CVE-2013-0333. All users are strongly encouraged to update when possible. This vulnerability exposes ActiveSupport to unsafe query generation. More information on the vulnerability can be found here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0333, and in this post: https://groups.google.com/d/topic/rubyonrails-security/1h2DR63ViGo Downloads RPM packages for are available at https://yum.puppetlabs.com/el or /fedora Debian packages are available at https://apt.puppetlabs.com Source can be downloaded from https://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.2.21.tar.gz, along with the accompanying signature file, https://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.2.21.tar.gz.asc. See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet 1.2.21 Security Fixes Michael Koziarski (1): Add an OkJson backend and remove the YAML backend -- 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] How to collect hostnames or host ips
I'd like to be able to collect all the hostnames (fqdn) or ips of certain
hosts to be used in setting up firewall rules. I'd like to search for
hosts that have included a particular class, perhaps by simply setting a
tag when that resource is included.
eg:
node 'node1' {
include 'somewebclass'
}
class somewebclass {
tag 'web'
# other stuff
}
Then in another class, I'd like to find all my 'web' hosts and allow them
access in a firewall rule.
eg:
class somedbclass {
tag 'db'
iptables { allow db access:
proto = 'tcp',
dport = '3306'
source = Node | tag == 'web' |,
jump = 'ACCEPT'
}
}
So, ultimately, I'd need that Node | tag == 'web' | to be an array of
hostnames or ipaddresses.
This is just an example to try to explain what I am doing. Does anyone
know how to do this? Can I do this in puppet? Do I need to write my own
function to handle this? Or, can I use something like hiera or puppetdb to
do this?
Thanks for any tips.
--
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] Extending a standard type
You can set the default values to undef and then the standard user type
will use its defaults (if any). It usually makes sense to default the
ensure parameter to 'present' though because if it is undef then nothing
will happen:
define site::user (
$ensure = 'present',
$comment = undef,
$home = undef,
$password = undef,
) {
user { $title:
ensure = $ensure,
comment = $comment,
home = $home,
password = $password,
}
...
}
Note that $name and $title are the same thing so you probably shouldn't
specify a value for $name.
- Keith
On 27 January 2013 00:55, Matthew Pounsett matt.pouns...@gmail.com wrote:
I'm trying to extend the standard 'user' type to add maintenance of some
of the contents of a user's home directory, and I'm trying to avoid
creating an entirely new custom type if I can. The approach I'm taking is
to create a site::user defined type which in turns calls the standard user
type. I'm having a problem figuring out how to manage the optional
parameters.
The most likely path seems to be something like this (simplified for
example):
define site::user (
$comment,
$ensure,
$home,
$name = $title,
$password,
) {
user { $title:
comment = $comment,
ensure = $ensure,
home = $home,
name = $name,
password = $password,
}
}
The problem with this, of course, is that the parameters to site::user
aren't optional, and I'd like them to be. I've tried setting their
defaults to null strings, but I get errors about reassigning variables if I
do that.
Of course, this would be even better.. but doesn't appear to be a valid
syntax in puppet:
define site::user ( $**args ) {
user { $title:
$args
}
}
This seems to me to be the sort of thing that'd be in a puppet cookbook,
but google hasn't shown me any useful docs or examples for what I'm trying
to do. Does this approach even make sense, or is there a better way?
--
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.
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] Apache module
Hi all, I've spent a bit of time today investigating whether or not I can use the Puppet Labs Apache module - https://forge.puppetlabs.com/puppetlabs/apache I've noted this helpful blog post - http://blog.akquinet.de/2011/11/23/managing-an-apache-server-with-puppet/ However after examining the Apache configuration I've inherited it seems to me that the publicly available module exposes only a fraction of the Apache options in the manifests. E.g. I have inherited several hundred RewriteRules along with RewriteConds, and all that ugliness, non standards paths to files, non standard values passed to prefork and and worker MPM, and so on. In general, looking in templates/httpd.conf.erb file, though, it appears to me that the vast majority of Apache's configuration options can't be controlled by puppet if you use the Apache module. Rather they're hardcoded in this file. This leads me to suspect that most sites must be using Apache modules that were entirely developed in house? Or have most sites just decided that most of Apache's options shouldn't ever be changed from these default settings? Or is there a better Apache module I should look at? Or should I take the initiative and feedback lots and lots of changes to the module? Thanks in advance for feedback. Kind regards, Alex Harvey -- 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] Puppet issues
Hi,
I am newbie in puppet and just learning the things. I have created the
module to create users which is worked great. But I have created another
one for sysctl which doesn't updated on agent server and as well on the
puppet master itself.
Working for users add:
=
[root@puppet ~]# cat /etc/puppet/manifests/classes/users.pp
class users {
users::add { testsudo:
username= 'testsudo',
comment = 'Sudo Testing',
shell = '/bin/bash',
password_hash = '$1$ULu2WAcE$k6/d5orSPRxsJWDhlvEEf.'
}
users::add { testing:
username= 'testing',
comment = 'Sudo Testing',
shell = '/bin/bash',
password_hash = '$1$ULu2WAcE$k6/d5orSPRxsJWDhlvEEf.'
}
}
define users::add($username, $comment, $shell, $password_hash) {
user { $username:
ensure = 'present',
home = /home/${username},
comment = $comment,
shell = $shell,
managehome = 'true',
password = $password_hash,
}
}
=
Not working sysctl:
=
[root@puppet ~]# cat /etc/puppet/manifests/classes/sysctl.pp
class sysctl {
file { /etc/sysctl.conf:
ensure = present,
owner = root,
group = root,
mode = 0644,
}
}
define sysctl::settings ($ensure=present, $source=, $content=) {
$sysctl_file = /etc/sysctl.conf
exec { reload-sysctl-settings:
command = /sbin/sysctl -p ${sysctl_file},
require = File[$sysctl_file],
subscribe = [
File[$sysctl_file],
File[/etc/sysctl.conf],
],
refreshonly = true,
}
if $source {
file { $sysctl_file:
ensure = $ensure,
source = $source,
owner = root,
group = root,
mode = 0644,
notify = Exec[reload-sysctl-settings],
}
}
if $content {
file { $sysctl_file:
ensure = $ensure,
content= ${content},
owner = root,
group = root,
mode = 0644,
notify = Exec[reload-sysctl-settings],
}
}
}
define sysctl::lvs_direct_routing ($ensure=present) {
sysctl::settings { lvs-direct-routing:
priority = $priority,
ensure = $ensure,
source = puppet://puppet.domain.com/files/direct-routing.conf,
}
}
define sysctl::tcp_performance ($ensure=present) {
sysctl::settings { tcp-performance:
priority = $priority,
ensure = $ensure,
source = puppet://puppet.domain.com/files/performance.conf,
}
}
===
Re: [Puppet Users] Puppet issues
When you specify include sysctl then Puppet includes the sysctl class and
this class only ensures that the /etc/sysctl.conf file exists:
class sysctl {
file { /etc/sysctl.conf:
ensure = present,
owner = root,
group = root,
mode = 0644,
}
}
which it likely already does so Puppet does nothing. Your users class
calls some of your defined types so you see Puppet creating resources. I
expect you want to create some of your sysctl defined types in your sysctl
class as well.
You can supply --debug command-line option to see what Puppet is doing
under the hood.
- Keith
On 29 January 2013 06:05, linuxhack2...@gmail.com wrote:
Hi,
I am newbie in puppet and just learning the things. I have created the
module to create users which is worked great. But I have created another
one for sysctl which doesn't updated on agent server and as well on the
puppet master itself.
Working for users add:
=
[root@puppet ~]# cat /etc/puppet/manifests/classes/**users.pp
class users {
users::add { testsudo:
username= 'testsudo',
comment = 'Sudo Testing',
shell = '/bin/bash',
password_hash = '$1$ULu2WAcE$k6/**d5orSPRxsJWDhlvEEf.'
}
users::add { testing:
username= 'testing',
comment = 'Sudo Testing',
shell = '/bin/bash',
password_hash = '$1$ULu2WAcE$k6/**d5orSPRxsJWDhlvEEf.'
}
}
define users::add($username, $comment, $shell, $password_hash) {
user { $username:
ensure = 'present',
home = /home/${username},
comment = $comment,
shell = $shell,
managehome = 'true',
password = $password_hash,
}
}
=
Not working sysctl:
=
[root@puppet ~]# cat /etc/puppet/manifests/classes/**sysctl.pp
class sysctl {
file { /etc/sysctl.conf:
ensure = present,
owner = root,
group = root,
mode = 0644,
}
}
define sysctl::settings ($ensure=present, $source=, $content=) {
$sysctl_file = /etc/sysctl.conf
exec { reload-sysctl-settings:
command = /sbin/sysctl -p ${sysctl_file},
require = File[$sysctl_file],
subscribe = [
File[$sysctl_file],
File[/etc/sysctl.conf],
],
refreshonly = true,
}
if $source {
file { $sysctl_file:
ensure = $ensure,
source = $source,
owner = root,
group = root,
mode = 0644,
notify = Exec[reload-sysctl-settings]**,
}
}
if $content {
file { $sysctl_file:
ensure = $ensure,
content= ${content},
owner = root,
group = root,
mode = 0644,
notify = Exec[reload-sysctl-settings]**,
}
}
}
define sysctl::lvs_direct_routing ($ensure=present) {
sysctl::settings { lvs-direct-routing:
priority = $priority,
ensure = $ensure,
source =
puppet://puppet.domain.com/**files/direct-routing.confhttp://puppet.domain.com/files/direct-routing.conf
,
}
}
define sysctl::tcp_performance ($ensure=present) {
sysctl::settings { tcp-performance:
priority = $priority,
ensure = $ensure,
source =
puppet://puppet.domain.com/**files/performance.confhttp://puppet.domain.com/files/performance.conf
,
}
}
===
site.pp file:
===
[root@puppet ~]# cat /etc/puppet/manifests/site.pp
import classes/*
node default {
include users
include sysctl
}
node test {
include users
include sysctl
}
node 'server.domain.co' inherits test {
}
node 'shiva.domain2.co' inherits test {
}
If I run the command puppetd --server puppet.domain.com --waitforcert 60
--test from agent then it creates users but it doesn't update anything
about sysctl and even it doesn't throw any errors too. Even I have tried to
execute the command puppet -tv on puppet master itself which has the same
issue.
May I know where I am mistaking with sysctl?
--
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.
[Puppet Users] How to assign variable for an URL
Hi all,
I have written the following code...
$someendpoint1=12345
$someendpoint2=54321
$prop = /app/tcs/temp.properties
file{'temp.properties':
path =$prop,
ensure ='present',
content =$someendpoint1=http://sdrhuiswresw:8080/ersfrsdrs/sdersrsrs
$someendpoint2=http://sdrhuiswresw:8080/ersfrsdrs/sdersrsrs;
}
actually i want to apply variables to the link..when am trying to do that
am getting an error. How can i assign the variables to link???
Can sum one please help me with it.
--
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] Puppet Agent does not connect to master
Hi, we are running several debian squeeze (64 bit, no backports) and a puppetmaster (3.0.2). now i wanted to upgrade the agents from 3.0.1 to 3.0.2, and got stuck... the new 3.0.2 agents don't connect to the master... 3.0.1 agents still do... i run puppet master in debug mode, and didn't see any communications between agent and master... puppet and puppet.foo.bar are both resolving to the right puppet host, the machines are on the same subnet, and did work under 3.0.1 ;( the error from the 3.0.2 agents is root@jenkins:~# puppet agent --verbose --no-daemonize Notice: Starting Puppet client version 3.0.2 Warning: Unable to fetch my node definition, but the agent run will continue: Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet.foo.bar] Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet..foo.bar] Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet..foo.bar] Could not retrieve file metadata for puppet://puppet/plugins: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet.foo.bar] Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet.foo.bar] Notice: Using cached catalog Error: Could not retrieve catalog; skipping run Error: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet.foo.bar] /usr/lib/ruby/vendor_ruby/puppet/agent.rb:89:in `exit': no implicit conversion from nil to integer (TypeError) from /usr/lib/ruby/vendor_ruby/puppet/agent.rb:89:in `run_in_fork' from /usr/lib/ruby/vendor_ruby/puppet/agent.rb:86:in `fork' from /usr/lib/ruby/vendor_ruby/puppet/agent.rb:86:in `run_in_fork' from /usr/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `run' from /usr/lib/ruby/vendor_ruby/puppet/application.rb:175:in `call' from /usr/lib/ruby/vendor_ruby/puppet/application.rb:175:in `controlled_run' from /usr/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run' from /usr/lib/ruby/vendor_ruby/puppet/daemon.rb:205:in `run_event_loop' from /usr/lib/ruby/vendor_ruby/puppet/daemon.rb:167:in `loop' from /usr/lib/ruby/vendor_ruby/puppet/daemon.rb:167:in `run_event_loop' from /usr/lib/ruby/vendor_ruby/puppet/daemon.rb:145:in `start' from /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:357:in `main' from /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:313:in `run_command' from /usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run' from /usr/lib/ruby/vendor_ruby/puppet/application.rb:438:in `plugin_hook' from /usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run' from /usr/lib/ruby/vendor_ruby/puppet/util.rb:496:in `exit_on_fail' from /usr/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run' from /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:87:in `execute' from /usr/bin/puppet:4 -- 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.
