[Puppet Users] Re: Variable interpolation in class parameters
On Friday, September 30, 2011 4:50:33 PM UTC+1, jcbollinger wrote:
> I do think there's a bug, but I'm not confident it's the one you think
> it is. I find no documentation of any difference in variable
> interpolation in class parameter defaults than in any other context,
> so I expect the interpolation to be performed according to the same
> rules as elsewhere. Specifically, I expect interpolation to draw on
> only variables available in the scope in which the host string
> appears. A class's parameters cannot be in scope in that class's own
> parameter list definition, because their values are not known at that
> point. Therefore, you should not be able to interpolate one
> parameter's actual value into the default value of a another
> parameter. That is, NONE of the interpolations in your example should
> work.
>
Hi John,
This thing scaries me a bit.
I'm rewriting my modules in order to merge the usage of a params.pp class
where defaults are set and parametrized classes.
The output is something like :
class openssh (
[...]
$package = $openssh::params::package,
$service = $openssh::params::service,
$service_status= $openssh::params::service_status,
$process = $openssh::params::process,
$process_args = $openssh::params::process_args,
$config_dir= $openssh::params::config_dir,
$config_file = $openssh::params::config_file,
$config_file_mode = $openssh::params::config_file_mode,
$config_file_owner = $openssh::params::config_file_owner,
$config_file_group = $openssh::params::config_file_group,
$config_file_init = $openssh::params::config_file_init,
$pid_file = $openssh::params::pid_file,
$data_dir = $openssh::params::data_dir,
$log_dir = $openssh::params::log_dir,
$log_file = $openssh::params::log_file
) inherits openssh::params {
There is no particular interpolation on variables, just their value's
assignment as default.
Is this a supported behaviour that I can trust to be mantained on future
versions?
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/XriIlABmFyEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Custom Facts
>
> All I want to be able to do is set a variable on a per node basis that
> defines a functional grouping, ie a class of server, and query that with
> mcollective. Should not be difficult to do.
>
It isn't and it seems to me that you already know how to do it, just do not
try to assign that variable as a custom facts (it that doesn't show up in
the scope lookup) and set it in puppet manifests (or in the ENC), then set
factsource = yaml in mcollective config file and populate it with something
like:
file {"/etc/mcollective/facts.yaml":
owner=> root,
group=> root,
mode => 400,
loglevel => debug, # this is needed to avoid it being logged and
reported on every run
# avoid including highly-dynamic facts as they will cause
unnecessary template writes
content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s
=~ /(uptime.*|path|timestamp|free|.*password.*|.*psk.*|.*key)/ }.to_yaml
%>"),
require => Package["mcollective"],
}
I generally use this, in mcollective for custom variables like $role and
$role_group that are assigned on role classes that are included by nodes
(one node, one role).
The $role_group is useful, for me, to group all the machines (of different
roles) that cuncur to provide a service for users (they have all to work for
the service to be usable).
And trust me, when you can check in few seconds, whatever is relevant to a
site or a service offered to your users with something like:
mc-puppi check -F role_group=appstore
you are happy, but that's another story.
My2c
al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/f8SYI1w3xiEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: 'requires' dependency in file-fragments pattern was not honored
Hi Jon,
I personally don't use (and don't see much value added, but I'm open to
alternative opinions) the "new"
Exec["Assemble_Sudo_Fragments"] ~> Exec["Validate_Check_File"] ->
File["Make_Sudo_File_Live"]
syntax to manage dependencies, so I can't say why it didn't work as
expected.
I would rather try adding the require argument here:
file {"Make_Sudo_File_Live":
path=> "/etc/sudoers",
source => "${s_sudo::params::sudo_check_file}",
mode=> 440,
owner => root,
group => root,
*require => Exec["Validate_Check_File"],*
}
Alessandro
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/t6NW9hOQAhkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Modules for Solaris
On Wednesday, July 20, 2011 5:24:05 PM UTC+2, deet wrote: > > > On Jul 20, 12:06 am, "Al @ Lab42" wrote: > > I'm considering the opportunity of adding (basic) Solaris support to my > > Cool. Certainly that will make it easier on Solaris admins new to > puppet. > > Hope so. My intention is at least to setup basic system configuration and adding applications management when needed. > > > > > > So let's begin with few points: > > > > - What version? > > I'm tempted to begin only with Solaris 10, > > I think initial Solaris 10 support would be the most valuable. > Keep in mind Solaris 11 is going to ship in a few months and I > personally think 10 and 11 will co-exist for years to come. > Additionally what ever you put together for Solaris 10 support would > mostly work on Solaris 9 as well. > > > > > - What packages? > > This might become a nightmare... > > Solaris admins are used to this nightmare:) We build and version our > own packages with the occasional dip into Steve's Sunfreeware package > repo. > > > > > - What package manager? > > We use vanilla Solaris package which is wrapped in a define to give us > package version control. Solaris 11 will come with the new IPS > packaging system so that will be another alternative. I could > imagine using IPS and the traditional pkgadd/pkgrm toolset on the same > host to even complicate things more. > > > > > If someone if interested is collaborating on this effort, just contact > > me > > We'd be happy to give you what we have but they are not in > publishable format because of the lacking documentation. > Really thanks, for the notes and the modules. They have been and will be really useful (IMHO you should publish them anyway, whatever the documentation... :-) > Good luck! > Derek. > > > > All the best > > Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/f8F-qbjkCL0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Modules for Solaris
Thank you for the valuable infos, I agree that differences are enough to require a dedicated solaris subclass, to keep changes isolated and don't fiddle with existing classes linux oriented. The approach: "Custom packages using pkgadd, Solaris OS packages using pkgutil, OpenCSW using pkgutil." seems sane to me and flexible enough to manage exotic packages. Are your modules, Aareon, published somewhere? I've learnt a lot about Solaris (and its madness :-) just seeing Deet's ones... Ciao al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4hox7_nnfhUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Modules for Solaris
I'm considering the opportunity of adding (basic) Solaris support to my modules ( www.example42.com) but before starting I'd like to gather some info about best practices and standards. I've to admit that I've not a great working Solaris experience, so I actually don't know how people use it, what versions are more used and so on. So let's begin with few points: - What version? I'm tempted to begin only with Solaris 10, in order to avoid too many complications. Question is... does this makes sense? What versions of Solaris are currently most used? Since I believe that the best approach to puppettization is to replicate on new machines the current envrionments without installing Puppet on existing production servers, does make sense the assumption that people would generally upgrade their older boxes to brand new Solaris 10 setups? I know that mileage may vary, but whatever better informed opinion is welcomed. - What packages? This might become a nightmare... there are different packages repositories, blastwave, openCSW, Sunfreeware... , to make modules that manage the same software from different sources might be a troublesome and I would like to stick to one. Does this makes sense? What's the most used / updated /large package repository out there? Do you use any of these on production environments? - What package manager? Can I assume that (almost) everybody uses (in 2011) pkgutil to install software on Solaris? If not, what are the alternatives? - Existing modules for Solaris? Has anyone published Puppet modules for Solaris? Can you link them here, for reference and inspiration... There questions might appear particularly naive to a more experienced Solaris sysadmin but I have to start from some basic points and as usual, "better ask to the experts"... Thanks for any feedback you might want to leave on these questions and to whatever advice you might give about Puppet on Solaris. If someone if interested is collaborating on this effort, just contact me All the best Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/yi-nY02p06AJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Using puppet to import database on client side
Seems like the command /usr/bin/mysql -uroot -proot papa < filedump.sql returns an error when executed. Try to run it directly to understand why and note that you have to eecute it only once and not at every Puppet runs, that is achieved with refreshonly => true, or unless => "a command that checks if the exec has been done and returns true", Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/d3cUqUNnMVQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Using puppet to import database on client side
The quick way is to apply a pair of exec resources on the client machine:
- One that downloads the sql file and the other one (that requires the first
one) that applies it.
Something like:
exec {
"Retrieve $url":
cwd => "$work_dir",
command => "wget $url",
creates => "$work_dir/$sql_filename",
timeout => 3600,
}
exec {
"Extract $sql_filename":
command => "mysql $mysql_options < $work_dir/$sql_filename",
unless => "command that checks if the queryfile has been
processed",
require => Exec["Retrieve $url"],
}
An alternative approach would be to use puppi to "deploy" the sql file using
this define:
http://github.com/example42/puppi/blob/master/manifests/project/mysql.pp
In order to do this you should:
- Include puppi in your modules ( http://github.com/example42/puppi )
- Write a define like for your client node
puppi::project::mysql { "mysite_sql":
source => "http://url_to/mysite.sql";,
mysql_user => "$mysql_user",
mysql_host => "$mysql_host",
mysql_database => "$mysql_database",
mysql_password => "$mysql_password",
report_email => "my@mail",
enable => "true",
}
- MANUALLY TYPE "puppi deploy mysite_sql" on the client node (or trigger it
via Puppet with an exec resource like the ones at the beginning).
Note that this Puppi approach might be a bit overkill for your needs: if you
have to apply the sql file statements only once the first approach is
quicker, if you plan to manage more or less continuous application
deployments where developers leave on http://url_to/mysite.sql the changes
on the database they require, the puppi approach saves time in the long term
(and gives a lot of extra features).
My2c
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/5rmN0_gmyQ4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: how to write classes to install package from source
Thanks for the suggestions, they are going to be merged.
That's a define I did various years ago that actually has been useful in
various cases (I do agree that it's better to use packages, but sometimes
this is the quickest and saner approach).
Al
On Wednesday, July 13, 2011 8:53:33 AM UTC+2, vagn wrote:
>
> On 07/12/2011 06:19 AM, Al @ Lab42 wrote:
> > command => "mkdir -p $destination_dir ; cd
> > $destination_dir ; $extract_command $work_dir/$source_filename",
> Nice. But I would suggest changing ';' to '&&'. That way, if the
> mkdir or cd fail you don't end up
> trying to extract the archive in the wrong directory.
>
>command => "mkdir -p $destination_dir && cd $destination_dir &&
> $extract_command $work_dir/$source_filename",
>
> Also consider
>
>unless => "test -d ${destination_dir }/${extracted_dir}",
>
> or even better
>
>creates => "${destination_dir }/${extracted_dir}",
>
> for the repetition guard.
>
> --
> vagn
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/EjT5lFqc31MJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: how to write classes to install package from source
You might find this define useful (
https://github.com/example42/puppet-modules/blob/master/common/manifests/defines/netinstall.pp
):
define netinstall (
$url,
$extracted_dir,
$destination_dir,
$owner = "root",
$group = "root",
$work_dir = "/var/tmp",
$extract_command = "tar -zxvf",
$preextract_command = "",
$postextract_command = ""
# $postextract_command = "./configure ; make ; make install"
) {
$source_filename = urlfilename($url)
if $preextract_command {
exec {
"PreExtract $source_filename":
command => $preextract_command,
before => Exec["Extract $source_filename"],
refreshonly => true,
}
}
exec {
"Retrieve $url":
cwd => "$work_dir",
command => "wget $url",
creates => "$work_dir/$source_filename",
timeout => 3600,
}
exec {
"Extract $source_filename":
command => "mkdir -p $destination_dir ; cd $destination_dir ;
$extract_command $work_dir/$source_filename",
unless => "find $destination_dir | grep $extracted_dir",
require => Exec["Retrieve $url"],
}
if $postextract_command {
exec {
"PostExtract $source_filename":
command => $postextract_command,
cwd => "$destination_dir/$extracted_dir",
subscribe => Exec["Extract $source_filename"],
refreshonly => true,
timeout => 3600,
require => Exec["Retrieve $url"],
}
}
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/cWUfes0R9OkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: A working firewall module
Thanks for the feedback and the bug report, Ronen.
I'll check it..
On Monday, July 11, 2011 3:28:27 PM UTC+2, Ronen wrote:
>
> Hey Alessandro the module works well, one issue that I had is that once
> rules were applied the iptables service wasn't restarted, iv dug through the
> code and indeed saw the notify under rule.pp:
>
> concat::fragment{ "iptables_rule_$name":
> target => "${iptables::params::configfile}",
> content => "$command $chain $true_rule -j $target\n",
> order => $true_order,
> ensure => $ensure,
> notify => Service["iptables"],
> }
>
> My guess is that the notify should be defined deeper in the defined
> resource?
>
> The only way I was able to make it restart was to use:
>
> File["/etc/sysconfig/iptables"] ~> Service[iptables]
>
> Ronen
>
> On Mon, Jul 11, 2011 at 12:59 PM, Ronen Narkis wrote:
>
>> Just did,
>>
>> Thank you!
>> Ronen
>>
>>
>> On Mon, Jul 11, 2011 at 1:50 AM, Ken Barber wrote:
>>
>>> Hi Ronen,
>>>
>>> Making the rules persistent is a matter of running iptables-save
>>> afterwards. If you drop this in your top scope it should work:
>>>
>>> exec { "persist-firewall":
>>> command => $operatingsystem ? {
>>>"debian" => "/sbin/iptables > /etc/iptables/rules.v4",
>>>/(RedHat|CentOS)/ => "/sbin/iptables > /etc/sysconfig/iptables",
>>> }
>>> refreshonly => true,
>>> }
>>> Firewall {
>>> notify => Exec["persist-firewall"]
>>> }
>>>
>>> Can you raise a bug on the other issue about not detecting existing
>>> rules? I'd appreciate being able to see any problematic rules (after
>>> your own scrubbing of course). We'll then be able to try and fix it
>>> for you.
>>>
>>> https://github.com/puppetlabs/puppetlabs-firewall/issues
>>>
>>> Alessandro's suggestions still hold true about applying firewall rules
>>> with related classes. I'm a big fan of this methodology instead of
>>> having a long list of rules. This is why a firewall type that handles
>>> individual rules is a good approach.
>>>
>>> ken.
>>>
>>> On Sun, Jul 10, 2011 at 9:54 PM, Ronen Narkis wrote:
>>> > Hey Ken, the main issue was that the provider wasn't detecting existing
>>> > rules but instead kept adding them in, another issue is that the rules
>>> > aren't persistent (restarting the service clears them out),
>>> >
>>> > Alessandro ill check it out thanks!
>>> >
>>> > Ronen
>>> >
>>> >
>>> >
>>> > On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber <
>>> kgbbe...@gmail.com>
>>> > wrote:
>>> >>
>>> >> I have been working on doing something similar to this. We want to
>>> >> abstract for multiple OS's and deal with the joy that is Solaris
>>> zones.
>>> >> Essentially, it will be a resource that defines the fw rules in XML
>>> and
>>> >> then a script takes all of those definitions and creates a complete
>>> set of
>>> >> firewall rules.
>>> >> I am waiting to hear back on our code release policy to see what it
>>> takes
>>> >> to release it once I am done.
>>> >> -- cwebber
>>> >> On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote:
>>> >>
>>> >> FYI
>>> >> I don't know it it may be useful , but I've done this:
>>> >> https://github.com/example42/puppet-modules/tree/master/iptables
>>> >> which can be used in 2 ways:
>>> >> - a "standard" iptable-save approach (set $iptables_config = "file"
>>> before
>>> >> to enable it) with rules file defined in
>>> >>
>>> https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp
>>> >> (here you have to add source or content arguments to mange it with
>>> static
>>> >> files or templates according to your need)
>>> >> - an "automatic" way (default option when you include the module) that
>>> >> dymanically builds iptables rules according to the modules you include
>>> and
>>> >> the iptables related
Re: [Puppet Users] Monitoring abstraction and test driven infrastructure deployment
On Friday, March 18, 2011 5:33:25 PM UTC+1, T.J. Yang wrote: > > Hi, Al > > > I am interested to participate the effort to add system monitoring > function/feature into puppet. > > I like following equation ;) > > puppet=configuration management + asset management + system monitoring > Yeah, I totally agree, I am a xymon(hobbit/bb) user, I only see your doc mention nagios, so I > could be helpful. > Interesting. If you want contact me privately, if you give me few quick hints and best practices on how to configure Xymon I think I can do the connector and the relevant module quite quickly. > Should open up wiki page on puppet wiki to document this effort ? > I can do the wiki init work if you agree. > Well, why not, but I think we should ask to the PuppetLabs guys. While generally the monitoring automation and abstraction is something probably interesting for everybody, my own implementation implies choices that might not be generally approved. All the best Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet Camp Announcements
+1 for Deepak as Master of Ceremonies! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Monitoring abstraction and test driven infrastructure deployment
Good afternoon (morning|night) all, I've just posted an article on how I manage automatic monitoring with Puppet http://www.example42.com/?q=Test_Driven_Puppet_Infrastructures_deployment and besides the shameless spam on this list I'd like to take this occasion to raise again a topic discussed with Nigel, Dan and others in the last Puppetcamp, in this list and somewhere else in the past. We all think, I suppose, that Puppet should somehow manage automatically the monitoring of the resources it provides. How this is done is a whole universe of complexity, alternative approaches and design decisions. What I've done is an attempt to use standard naming to define what to monitor in an abstract way (without reference to the tool actually used for monitoring) and a (working in different productions) implementation entirely based on Puppet DSL that prefers linearity and extendability over performance and optimization of resources. I think it would be interesting to know how people are dealing with this topic and how/when this will eventually implemented directly in Puppet code. All the best Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Nagios monitoring with example42 modules
Hi Pete, On Monday, February 28, 2011 9:47:36 PM UTC+1, pete ehlke wrote: > > Folks: > > I've started to play around with the comprehensive integrated module set > from example42 (http://www.example42.com/). > > Following the instructions, I set up one node as a nagios server, with > 'include nagios'. I set up another node to be monitored via nagios, with > 'include nagios::target". I set $monitor=true for the base node, which is > inherited by both the nagios server and the target node, and I set > $monitor_type = ["nagios", "munin"], and I set $monitor_tool = "nagios". I > find the target's nagios resources exported to the storeconfigs database, > eg: > > | 105 | /etc/nagios/auto.d/services/client.example.com-apache_process.cfg > | File | 2 | 4 |1 | 45 | > 2011-02-28 20:43:14 | 2011-02-28 20:43:14 | > > However, though both systems are monitored by munin in this setup, the > nagios server never seems to monitor the target > node. /etc/nagios/auto.d/services/client.example.com-apache_process.cfg and > friends do not get created on either system. > > Is anyone from example42 around to help point out where I'm being stupid > here? > > Yes. Your setup doesn't seem to have something particularly wrong, but if you want to replicate a working layout try this: Set for all nodes: $monitor = "yes" $monitor_tool = [ "nagios" , "munin" ] And on you Nagios server: include nagios That should be enough. Consider that you do not need anymore to include nagios::target on the nodes to be monitored and that the variable $monitor_type is not used (eventually tell me where you've read about it... the could be a mistake in the documentation). One thing that could be the cause for your problem is the variable $nagios_grouplogic that is useful if you need different Nagios servers checking nodes according to custom grouping logic. If undefined your Nagios server should monitor all the nodes registered to the same puppetmaster. Please, let me know if this helps. Best regards, Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet Enterprise
Congratulation for the approach you followed to balance the open source nature of Puppet and the need of your company to release a commercially scalable product/service. I think you've found out a sane compromise that should make everybody happy. Hope PE will be a very successful product. All the best Alessandro -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Using puppet to redeploy staging app
On Monday, January 17, 2011 10:33:33 AM UTC+1, Romain PELISSE wrote:
>
>
> @lab42: Your Puppi module sounds quite interesting indeed. I guess I could
> probably reduce the amount of "junk" in my current puppet configuration
> using it. I'll look into it in the next days.
>
Sweet. If you have any questions about it don't hesitate to ask.
It' currently under active development and things might be tweaked and
refined.
There are also few examples so maybe it's not clear how to use it.
For example you can do things like this (these are real life exaples with
some names changed):
puppi::project::war { "myapp":
source =>
"http://deploy.example42.com/myapp/myapp.war";,
user => "myappuser",
init_script => "tomcat-myapp",
deploy_root => "/store/tomcat/myapp/webapps",
report_email => "depl...@example42.com",
enable => "true",
disable_services=> "monit puppet apache2",
}
or (the maven project layout to get stuff from a Nexus repo will be
rewritten)
puppi::project::maven { "myapp":
source =>
"http://nexus.${domain}/nexus/it/example42/myapp/";,
user => "${apache::params::username}",
deploy_root => "/store/tomcat/myapp/webapps",
init_script => "tomcat-myapp",
firewall_src_ip => $type ? {
dr => "192.168.50.1/30",
prod => "192.168.38.1/30",
},
report_email => "depl...@example42.com",
enable => "true",
}
puppi::project::tar { "myapp":
source =>
"http://release.example42.com/deploy/myapp/release.tgz";,
init_source =>
"ssh://deploy@debian.${domain}/var/www/deploy/initdir/myapp/",
init_script => "apache",
deploy_root => "/store/www/myapp/",
report_email => "depl...@example42.com",
enable => "true",
}
Note finally, that during deploys puppi makes pre and post local checks
which are autopopulated if you use the example42 monitor classes. Since you
won't probably have them you might find empty checks (or an error, haven't
tried this condition).
Feedbacks welcomed
Alessandro
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Using puppet to redeploy staging app
To manage application deployments I've written this Puppi module: https://github.com/example42/puppet-modules/tree/master/puppi it's been designed originally to configure deployments procedures via puppet but it has to be run directly from the target node (until I'll write a mcollective agent) . So via Puppet you can manage the whole configuration, but not the execution itself. In the project dir there are some examples of deploy procedures that can adapt to different cases, (incidentally puppi::project::maven is intended to pull from a Nexus repository (but it's currenly under redesign and it works just for wars deploys) but these can be totally customized or created from scratch using using custom scripts. The advantages I see with this Puppi are: - A sort of bridge between Puppet and the OS for managing "shot" operations. - Standard syntax to manage deploys (and rollbacks) for different cases: you always have to write: puppi deploy - Once configured your deployment templates it's very quick and easy to setup deploy procedures on different servers with Puppet - Since the puppi command just executes, in a given seguence, a serie of commands, these can be totally customized, existing scritps can be adapted and different scripting languages used. - The "puppi check" command to see if on your node everything is running fine is incredibly handy (but for having this to work in an automated way you need the Example42 monitor classes) - The notification of the deploy result is customizable. For the moment it just sends and email, but you can do whatever you may want to do with a custom script. In the future I'd like to integrate Puppi with mcollective and provide a web frontend, at least for reporting. But works are in progresss and various things will change. Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Best Practices/Style: add stuff to a file for each host?
On Wednesday, January 12, 2011 5:08:07 PM UTC+1, Robin Lee Powell wrote:
>
> On Tue, Jan 11, 2011 at 12:07:30PM -0800, Robin Lee Powell wrote:
> > On Tue, Jan 11, 2011 at 05:20:38AM -0800, Al @ Lab42 wrote:
> > >
> > > You can build a file based on different "fragments" at least in
> > > 2 ways:
> > >
> > > - When you specify an array of templates , when using the
> > > content => argument, these templates are actually appended in
> > > the defined order.
> >
> > Can you use exported resources to generate such an array?
>
> Anybody? I can see how to generate resources from lots of hosts and
> run it on one host, but I can't see how to generate a config file
> out of all of that information.
>
> -Robin
>
I give you an example I use for Nagios.
On each node I've something like:
nagios::host { $ fqdn }
This calls the custom define (ignore the various frills such the grouptag
selector that manages different Nagios servers according to custom logic or
the various nagios::params variables, that are just module's internal
variables defined in the separated nagios::params class and concentrate on
the fact this this defines just exports a file resource: @@file ):
define nagios::host (
$ip = $fqdn,
$short_alias = $fqdn,
$use = 'generic-host',
$nagios_parent = '',
$ensure = 'present',
$hostgroups = 'all' ) {
require nagios::params
@@file { "${nagios::params::customconfigdir}/hosts/${name}.cfg":
mode=> "${nagios::params::configfile_mode}",
owner => "${nagios::params::configfile_owner}",
group => "${nagios::params::configfile_group}",
ensure => "${ensure}",
require => Class["nagios::extra"],
notify => Service["nagios"],
content => template( "nagios/host.erb" ),
tag => "${nagios::params::grouptag}" ? {
'' => "nagios_host",
default => "nagios_host_$nagios::params::grouptag",
},
}
}
On the Nagios server I 've (in order to collect all the exported reources
with the relevant tag)
case $nagios::params::grouptag {
"": {
File <<| tag == "nagios_host" |>>
File <<| tag == "nagios_service" |>>
# File <<| tag == "nagios_hostgroup" |>>
}
default: {
File <<| tag == "nagios_host_$nagios::params::grouptag" |>>
File <<| tag == "nagios_service_$nagios::params::grouptag" |>>
# File <<| tag == "nagios_hostgroup_$nagios::params::grouptag" |>>
}
}
Now, I could place (and maybe I will) , in the nagios::host define something
like:
@@concat::fragment { "nagios_hosts_${name}.cfg":
target =>
"${nagios::params::customconfigdir}/hosts/nagios_hosts.cfg",
ensure => "${ensure}",
notify => Service["nagios"],
content => template( "nagios/host.erb" ),
tag => "${nagios::params::grouptag}" ? {
'' => "nagios_host",
default => "nagios_host_$nagios::params::grouptag",
},
and in the nagios server class collect these fragments with:
case $nagios::params::grouptag {
"": {
Concat::fragment <<| tag == "nagios_host" |>>
Concat::fragment <<| tag == "nagios_service" |>>
# Concat::fragment <<| tag == "nagios_hostgroup" |>>
}
default: {
Concat::fragment <<| tag == "nagios_host_$nagios::params::grouptag"
|>>
Concat::fragment <<| tag ==
"nagios_service_$nagios::params::grouptag" |>>
# Concat::fragment <<| tag ==
"nagios_hostgroup_$nagios::params::grouptag" |>>
}
}
In the same server I should also define the base concat file with something
like:
concat { "${nagios::params::customconfigdir}/hosts/nagios_hosts.cfg":
mode => 644,
owner => root,
group => root,
}
Consider that I've not tested this , and there could be syntax or other
errors around .
Also I'm not so sure that is safe to have the double colons in the define
name when collecting it ( Concat::fragment ) but the principle is that.
Remember also that all the variable or facts you use when exporting a
resource (such as $fqdn ) are referred and valued on host that exports it
and not to the one that collects them.
Hope it helped without adding confusion
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Best Practices/Style: add stuff to a file for each host?
Hi On Tuesday, January 11, 2011 5:51:07 AM UTC+1, Robin Lee Powell wrote: > > (I'm going a bit more for philosophical discussion than practicality > here, maybe. Do at least feel free to think in terms of what Puppet > *should* do rather than tha fastest way to solve this problem.) > > There's a pattern I've run into a lot recently mhere a config file > needs to be built based on information from a number of puppet > managed hosts. Assume here than I mean "node" in the puppet sense > when I say "host". *shrug* > > Use cases: > > - backups, where each host has directories that need to be backed > up, and things need to be done on the individual backup client > hosts to handle that, and *also* stuff needs to be done on the > backup master > > - deploy configuration, where each host has a deploy role and it > makes most sense to talk about the deploy role in each host's > puppet config, but the file that manages the deployment is on > the deploy master host > > - VM configuration, where information about a VM needs to affect > data/configuration stored on the host that holds that VM > > All the same general pattern of action-at-a-distance: configuration > on a number of hosts affecting the master config file on a single > host. > This is exactly the case when you need exported resources and, therefore, storeconfigs. http://projects.puppetlabs.com/projects/1/wiki/Exported_Resources Also, multi-part config files: in at least some of these cases, the > information from each host generates some configuration file output, > perhaps from a template, but all of those bits of config file need > to be merged together into one master config file. > You can build a file based on different "fragments" at least in 2 ways: - When you specify an array of templates , when using the content => argument, these templates are actually appended in the defined order. - With the puppet-concat module by Rip https://github.com/ripienaar/puppet-concat you can build up files based on different fragments (and you can define single fragmensts as exported resources so that they fit the need you expressed). Incidentally, I've started to use it just yesterday, to build named.conf in a bind module, and does exactly what it says. Hope it helps Af -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to show a custom message during a puppet run (at certain conditions)
Hardly controlling my ire ( :-) ) I must confess that the server is (sadly) an Ubuntu 10.04... Thanks anyway Af On Dec 3, 12:20 am, Avi Miller wrote: > Al @ Lab42 wrote: > > Now, please, don't tell me that I should make a php-oci8 package and > > distribute it, I know that. > > At the risk of raising your ire, are you aware that Oracle has already > made php-oci8 packages: > > http://oss.oracle.com/projects/php/files/EL5/x86_64/http://oss.oracle.com/projects/php/files/EL5/source/ > > Just wanted to make sure you were aware, as I've found many who are not. > > Cheers, > Avi -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to show a custom message during a puppet run (at certain conditions)
Hi Puppet Masters,
I've a small problem that would like to solve in a somehow elegant
way.
I need to install the oci8 module for php without using a pre-made
package.
The operation involves installing the Oracle client (already done via
Puppet), setting Oracle environments (already done via Puppet),
installing various php modules and components (done) and executing a
command that promtps the user for some data (more precisely the
command "pecl install oci8" and then, when prompted, the user has to
type something like "instantclient,/opt/instantclient_11_2".
Now, please, don't tell me that I should make a php-oci8 package and
distribute it, I know that.
Sadly I haven't found a way to provide what is prompted as an argument
to the pecl command and I don't know how to automate the user input
this without some "expect" madness (any usable alternative to automate
the reply to a single prompt?).
So, since this is an operation that has to be done only on the setup
phase on few servers, for me is Ok to leave this step to manual
intervention, BUT still I want Puppet to notify (and keep on notyfing)
the user unless it finds oci8 ("unless => "pecl info oci8").
I've tried with functions like warning or err but I haven't managed to
show their message on the puppet client and inside a resource (in this
case I was considering a sort of "fake exec", so that I could use the
mentioned uness parameter to check for the extension existence and
show the message only when necessary).
So, just to be clear.
I would like to know, in order of preference:
- How to automate in a sane way via pecl the oci8 installation
withouth using a package
- Or how to show a warning message explaining how to do that manually
when the module is not installed.
I have the feeling that the answer to the second question is somehow
trivial, but somehow not enought for me.
Oh, by the way, Puppetmaster is still 0.25
Any help appreciated. Final outcome will be made public on
example42.com as (almost) usual.
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: RFC: Make file content specification methods consistent.
On Oct 30, 4:45 pm, Nigel Kersten wrote:
> http://projects.puppetlabs.com/issues/5158
>
> --- Ticket description ---
>
> We have four main ways we can specify file content in a file resource.
>
> The source parameter
> The content parameter
> The file function
> The template function
>
> These behave inconsistently in the following ways.
>
> The source parameter, file function and template function all can take
> an array. For source/file, the first file that exists will be used.
> For the template function, we concatenate the templates instead.
>
> The file function takes fully qualified paths only. The template
> function takes fully qualified paths, or dereferences relative paths
> as follows. ‘foo/bar.erb’ –> modules/foo/templates/bar.erb
>
> The latter problem is relatively easily solved, particularly if we
> implement #4885
>
> We are going to have to break backwards compatibility to solve the
> first problem however.
>
> My feeling is that more people make use of the multi-select logic in
> the source parameter/file function than make use of the concatenation
> of the template function.
> ---
>
> I'm opening this up for discussion here on the user list as we need to
> all agree whether it's worth chasing consistency here at the cost of
> breaking backwards compatibility.
>
> It appears that people use both the concatenation and multi-select
> logic. How can we provide both bits of functionality for all these
> methods?
>
> Here's a terrible suggestion that hopefully inspires a better one.
> An array indicates multi-select logic, separation with a colon means
> concatenate.
>
> 1a. Use the first source that exists.
>
> file { "/tmp/somefile":
> source => ["puppet:///modules/foo/somefile.$hostname",
> "puppet:///modules/foo/somefile.default",]
>
> }
>
> file { "/tmp/somefile":
> content => template("foo/somefile.$hostname.erb",
> "foo/somefile.default.erb"),
>
> }
>
> 1b. Concatenate multiple objects
>
> file { "/tmp/somefile":
> source =>
> "puppet:///modules/foo/somefile.$hostname:puppet:///modules/foo/somefile.default",
>
> }
>
> file { "/tmp/somefile":
> content => template("foo/somefile.$hostname.erb:foo/somefile.default.erb"),
>
> }
>
> Is this so unsatisfactory that we need to add more parameters? What if
> we pluralized for the concatenation with "sources" and "contents" ?
>
> 2b. New parameter for concatenation.
>
> file { "/tmp/somefile":
> sources => ["puppet:///modules/foo/somefile.$hostname",
> "puppet:///modules/foo/somefile.default",]
>
> }
>
> file { "/tmp/somefile":
> contents => [template("foo/somefile.$hostname.erb",
> template("foo/somefile.default.erb")],
>
> }
IMHO both the alternatives are OK, and, referring to the post's
followups, I prefer something like sources to source_concat and would
avoid the use of a "concatenate" boolean parameter to influence the
behaviour of another parameter (source/content): better to have the
information of how files are provided in a single parameter.
But basically it's just a matter of aestetics.
> Alternatively, do we really need to fix this? I think we do, as
> consistency matters a lot to me, but maybe I'm on my own here
Not at all, you're right, this has to be fixed.
My c
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Helping us prioritize issues.
+1 ;-D On Oct 24, 8:41 pm, Nigel Kersten wrote: > I know James has emailed about this before, but we have a lot of issue > prioritization to sort out in the very near future, so I wanted to make sure > the community is aware of ways you can communicate your own priorities to us > so we can take this into account. > > This does require that you have an account in our ticketing system > onhttp://projects.puppetlabs.com. > > If you don't have such an account, you can create one > here:https://projects.puppetlabs.com/account/register > > Once you're logged in with this account, you can "watch" issues. > > This will mean you'll get emailed about any updates, but just as > importantly, it also means we *know* that you care about this particular > issue, as the list of watchers is very visible. > > This doesn't mean we don't want to see coherent arguments or suggestions in > the issue log itself, those are always welcome, but it's all too easy for us > to lose track of a "+1" in an email thread or IRC. > > Thanks, > > Nigel > > -- > Nigel Kersten > Product Manager, Puppet Labshttp://www.puppetlabs.com > Twitter: @nigelkersten -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
On Oct 19, 11:06 pm, "R.I.Pienaar" wrote: > - "Al @ Lab42" wrote: > > > > > Hi List, > > I would like to discuss with whoever is interested one topic that I > > suppose has general interest. > > > I want to implement some kind of automatic testing on the status of a > > node after a Puppet Run. > > These tests involve trivial and less trivial things things like: > > - A local service is running > > - A local port is open > > - A remote server on a remote port is reachable by the node > > - An URL replies with an expected content > > - Some specific function needed by the node and provided by a remote > > host is working (ie: ldap acces for users authentication, ntp > > sync...) > > - Whatever other check that asserts that the node is correctly > > working > > sounds like things you want to monitor anyway in an ongoing manner? Generally yes. > > So assuming you have monitoring for all of this, is the problem that you > want visibility of the state right now after a run and not when nagios > gets round to doing its next checks which might be many minutes? Yes, but also I want direct correlation between a puppet run and an eventual failure. > I favor nrpe - cos I can deploy my check logic with puppet - but I really > think you want your monitoring to cover all of this. > > To answer the 'now' part of it, I'd just notify via mcollective my nagios > box to do a check for all services on the node post puppet run. That could be an option but it wouldn't directly correlate the check's failure with a Puppet run. I think I would prefer to use the existing checks (so nrpe is perfect) but be able run them also outside Nagios. BTW, an implementation question. How do you suggest to manage the triggering of an action on the mcollective client from the PupetMaster, after a Puppet run on one of its clients? I suppose that using a custom report is the most logic approach, but what's the sanest way to actually deliver it? Having a service listening on a mcollective client node and send reports there? Using stomp messaging? How? Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Automating infrastructure tests on Puppet nodes after a puppetrun
On Oct 19, 10:52 pm, Nicolas Szalay wrote: > - "Al @ Lab42" a écrit : > > | Hi List, > > Hi, > > | I would like to discuss with whoever is interested one topic that I > | suppose has general interest. > | > | I want to implement some kind of automatic testing on the status of a > | node after a Puppet Run. > | These tests involve trivial and less trivial things things like: > | - A local service is running > | - A local port is open > | - A remote server on a remote port is reachable by the node > | - An URL replies with an expected content > | - Some specific function needed by the node and provided by a remote > | host is working (ie: ldap acces for users authentication, ntp > | sync...) > | - Whatever other check that asserts that the node is correctly > | working > | > | I want to do this directly in my modules, at least for the checks > | that are directly related to the resources provided by the module > | and > | build some defines to manage quickly things like "check the url" or > | "check if the remote port is accessible". > | > | The point is to have a solid testing infrastructure, early > | notification of any problem that might take place after a Puppet run > | and, at the same time have a sort of monitoring logic that might be > | used also by other tools, like Nagios. > > Do you know about puppet-cucumber ? Yes, but as far as I've understood, puppet-cucumber is run on the Puppet Master and check resources managed by Puppet. I'd like also to make checks that might not be directly related to Puppet resources (but might be broken by a wrong config pushed via Puppet). > > | In order to achieve something like this there are different > | approaches and I would like to follow what seems most sane and, > | mostly, what could better fit the evolution of the Puppet ecosystem. > | > | Here a pair of examples: > | > | - APPROACH 1 - CHECK TRIGGERED BY PUPPET NODE > > This is an easy approach but how will you push information back to you ? I > have not checked but I don't think that the result of post run hooks are > included into reports In fact, and that's a reason why I don't prefer this approach, because you should build your own reporting stuff. > > | - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE > > I would use that one, combined with nagios through the mc nrpe agent probably > or something like a hudson instance to do a permanent check about this. +1 > > | Another point is how to organize and define the checks' list. > | Cucumber > | seems a nice and somehow "standard" way to define the checks logic, > | but could be also a plain execution of the different checks from a > | sort of wrapper script. > | The single checks could be nrpe commands and/or mcollective agents (I > | love the nettest one, incidentally). > | > | > | AFAIK there's nothing in the above examples that is particularly > | difficult or can't be done with existing tools, but I would like to > | introduce them seamlessly in my modules (using my monitoring > | abstraction classes). > | > | So, I wonder if someone is already doing similar checks, what's the > | approach they are following and what might be the evolution of Puppet > | under regarding these topics. > > Not doing it but definitely interested. I'll let you know if I make up something interesting :-) Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Automating infrastructure tests on Puppet nodes after a puppetrun
Hi List, I would like to discuss with whoever is interested one topic that I suppose has general interest. I want to implement some kind of automatic testing on the status of a node after a Puppet Run. These tests involve trivial and less trivial things things like: - A local service is running - A local port is open - A remote server on a remote port is reachable by the node - An URL replies with an expected content - Some specific function needed by the node and provided by a remote host is working (ie: ldap acces for users authentication, ntp sync...) - Whatever other check that asserts that the node is correctly working I want to do this directly in my modules, at least for the checks that are directly related to the resources provided by the module and build some defines to manage quickly things like "check the url" or "check if the remote port is accessible". The point is to have a solid testing infrastructure, early notification of any problem that might take place after a Puppet run and, at the same time have a sort of monitoring logic that might be used also by other tools, like Nagios. In order to achieve something like this there are different approaches and I would like to follow what seems most sane and, mostly, what could better fit the evolution of the Puppet ecosystem. Here a pair of examples: - APPROACH 1 - CHECK TRIGGERED BY PUPPET NODE After the Puppet run a script/command is launched and makes the necessary checks (built on the node in a dinamic way, according to the modules installed). If I'm not wrong in recent Puppet versions there's an hook that makes you run custom commands after (or before? or both?) the execution of the puppet run, so this might be the way to automate the start of the checks without too many hassles. The cons are that everything is done on the node and there's not (if not implemented specifically) a centralized management of checks runs, process logic, notifications and history. - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE This somehow intrigues me and requires the node to have a mcollective server deamon running. The automation might be triggered remotely by the mcollective client using mcollective agents available on the Puppet node. The mcollective client should be notified of the puppetrun and might not be the same PuppetMaster, and a way to do this might be via a custom report extention that reports directly to the mcollective client. The benefit is that the monitoring can be managed via mcollective and there's a central point where data are collected and commands executed. The list of checks to be done on the client should, IMHO, remain on the Puppet client (mcollective server) itself (no need to have store configs for this) and maybe a specific agent might be done to retrieve and run from the mcollective client the list of checks to perform. Another point is how to organize and define the checks' list. Cucumber seems a nice and somehow "standard" way to define the checks logic, but could be also a plain execution of the different checks from a sort of wrapper script. The single checks could be nrpe commands and/or mcollective agents (I love the nettest one, incidentally). AFAIK there's nothing in the above examples that is particularly difficult or can't be done with existing tools, but I would like to introduce them seamlessly in my modules (using my monitoring abstraction classes). So, I wonder if someone is already doing similar checks, what's the approach they are following and what might be the evolution of Puppet under regarding these topics. Any further or related idea is welcomed, Alessandro Franceschi -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Spaces in templates
On Sep 10, 5:20 pm, Brian Gallew wrote:
> Is there any reason why you don't just do it the easy way?
>
> host <%= users_ldap_servers.join(" ") %>
Nice.
Still the problem was elsewhere and what I thought to be an array
became a string.
Thanks anyway
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Spaces in templates
> Try <%= ldap + " " %>, or even force ldap to a string (ldap.to_s) if it > complains about not being able to add " " to a not-String. > Thanks for the reply Felix, actually it wasn't necessary any particular interpolation , I just discovered that actually I wasn't passing an array to the template... Regards, Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Spaces in templates
> It's weird also for me, but still I don't get the expected result. > Also with your suggestion... I found the problem. It's somehow my fault. In the way I manage variables. Now I've a totally different problem with my approach to set variables defaults, but that's another story... Thanks again Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Spaces in templates
On Sep 10, 2:57 pm, Dan Bode wrote:
> Hi Al,
>
> seems like its been a while :)
HI Dan,
yes indeed. But this time I should be more present. I've finally found
a job where I can actively work with Puppet, so I expect to pass much
more time around here.
> On Fri, Sep 10, 2010 at 5:50 AM, Al @ Lab42 wrote:
>
> > Hi all,
> > I've a silly problem that it's driving me crazy and I'm almost sure
> > the solution is quick and easy.
> > Still it doesn't seem at my reach.
>
> > I've a variable with an array of values, such as:
> > users_ldap_servers = [ "ldapm.example42.com" , "ldaps.example42.com" ]
>
> > I want to use these values in a single line of a template:
>
> > host <% users_ldap_servers.each do |ldap| %> <%= ldap %> <% end %>
>
> that's weird, it should not ignore your white spaces.
>
> I just tried:
>
> array<% array.each do |a| %> <%= a %><% end %>
>
> you could always use
>
> <%= "#{ldap} " %>
>
> as a last resort (although the above should work)
It's weird also for me, but still I don't get the expected result.
Also with your suggestion...
Thanks anyway
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Spaces in templates
Hi all, I've a silly problem that it's driving me crazy and I'm almost sure the solution is quick and easy. Still it doesn't seem at my reach. I've a variable with an array of values, such as: users_ldap_servers = [ "ldapm.example42.com" , "ldaps.example42.com" ] I want to use these values in a single line of a template: host <% users_ldap_servers.each do |ldap| %> <%= ldap %> <% end %> No matter how many spaces I place around, no matter the absence of trimming -%> I always get something like: host ldapm.example42.comldaps.example42.com instead of: host ldapm.example42.com ldaps.example42.com I think a solution could be to add a whitespace to "ldap" before yielding it... but I haven't found the needed "few chars combo" (I suppose). Any help? Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Pro Puppet
This is actually a question for James, but I think it's interesting for many out there. When the new book about Puppet is going to be released? Will it cover 2.6? All the best Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Variable Scoping = Root Canal
On Jun 28, 1:07 pm, Alan Barrett wrote:
> > Another approach is to do everything with node inheritance
>
> Common opinion seems to be that node inheritance should be avoided.
Just a comment about this "common opinion".
Given the fact that there's not the "right" way but the most fitting
one according to circumstances.
Given the fact that external node tools may be a good way to manage
nodes and their variables, but may not appeal everbody.
Given that extlookup does what it promises and avoids variables
scoping madness.
Given the fact that you can use facts to set variables (but I don't
think it's sane to set ANY kind of variable with facts)
I keep on considering the node's inheritance approach a viable,
working, flexible and even elegant solution to variables assignements
to nodes.
Just there are some point/precautions to consider:
- Include classes only at host-node level and set/override variables
wherever you want at step-nodes level (and this gives great
flexibility)
- Set in classes only local variables , not "environment" variables
that are used by other classes.
- If you really need to set in a class variables that are used by
other classes/modules use dedicated classes where you only set
variables (apache::params, apache:settings or whatever) and then
include these classes in all the classes that use the variables
defined therein and call the variables using their "absolute" name
( "${facility::params::ldap_server}" ) .
- Avoid, if possible to use inheritance in classes, and if you really
need to inherit classes beware of scoping hells and prefer the
inclusion of these "parameter" classes, where possible.
- Consider that variables set using their "absolute namespace" have to
be referred in classes with brackets and quotes
( $facility::ldap_server may not work) and that you can't use them in
templates (quick workaround is to reassign a variable inside a class: $
{ldap_server}" = ${facility::ldap_server}" )
My 5 cents
Al
PS: Still open to discussion
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Variable Scoping = Root Canal
On Jun 27, 8:25 pm, Douglas Garstang wrote:
> On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 wrote:
>
> > On 27 Giu, 09:02, Douglas Garstang wrote:
> >> I've been struggling with puppet variable scope all day, well, for
> >> several months actually.
>
> >> I think I have pretty simple requirements. For any given node, I want
> >> to be able to set a series of variables and include a set of classes,
> >> based on three different aspects of a node, being physical location,
> >> operating system, and function. If I try and do this with classes, I
> >> find that variables set in a class included from a node, are not
> >> visible to other classes included from that node.
>
> >> node 'node1.fr.xxx.com' {
> >> include facility::sjc
> >> include ldap::client
>
> >> }
>
> >> In this example, variables defined in facility::sjc are not visible in
> >> ldap::client (in this case, it would be the IP address of the local
> >> LDAP server).
>
> >> Another approach is to do everything with node inheritance, but in
> >> order to model these three functions, you end up with nodes with names
> >> like sjcDellBootServer or nycVmwareBootServer, which is just plain
> >> stupid.
>
> > Node names don't need to adapt to inheritance's logic.
> > You can do something like:
> > node sjc {
> > ldap_server="10.10.10.10"
> > }
>
> > node 'node1.fr.xxx.com' inherits sjc {
> > include ldap::client
> > }
>
> > When using nodes' inheritance the only real thing you've to care about
> > is to define variables BEFORE including any class.
> > So at the end it's better to include classes only in the node that
> > defines your host nad never in the "intermediary" nodes that can
> > represent facilities, networks or whatever.
>
> That's awful. If you can't build an inheritance tree from generic to
> specific, and assign variables at each step, that's a loss of a lot of
> functionality, and just about makes everything impossible.
You misunderstood. You can assign variables at each "step" in the
inheritance tree, and redefine them at more specific node steps.
It's just important to include whatever classes you need in your node
at the end of the inheritance tree, at the host-node level.
You could actually include classes in step-nodes only if they don't
use variables that might be defined (or redefined) at more specific
steps. That's why it's safer to include classes at the end, at host-
node level and define your variables, according to whatever logic you
need, in the nodes inheritance tree.
> And, even if I do that, only including classes in the final node...
>
> class A {
> $var = 1
>
> }
>
> class B {
> < do something with $var >
>
> }
>
> node A {
> include class A
> include class B
>
> }
>
> This doesn't work! But, it's doing what you suggested. Class B does
> not have access to $var, because it's out of scope. This is exactly
> what I want to do. I want to define an LDAP server variable in class
> A, and then use it in class B.
>
> Doug
You can do something like:
class B {
include A
< do something with ${A::var}
}
or, cleaner, define all your variables in a separated subclass that
can be included by every class that needs these variables (included
the same A class):
class B {
include A::params
< do something with ${A::params::var}
}
class A {
include A::params
# These A variables can be shared by other classes that include
A::params
}
Would this work?
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Variable Scoping = Root Canal
On Jun 27, 7:38 pm, Douglas Garstang wrote:
> The problem with doing something with "${facility::ldap_server}" is
> that it should really be called "${facility::sjc::ldap_server}", and
> when you do that, you completely destroy the whole point of
> inheritance. The ldap client module itself should not directly
> reference the "${facility::sjc::ldap_server}" variable, otherwise I
> would see one ldap module for each facility!
>
> Doug
Ok, right. Then you can do something like:
class ldap::client {
include facility
use "${facility::ldap_server}" in this class
}
And in the facility class manage the logic to assign to ldap_server
the value you want according to the actual facility (this might be a
variable you define in nodes or a custom fact).
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Variable Scoping = Root Canal
On 27 Giu, 09:02, Douglas Garstang wrote:
> I've been struggling with puppet variable scope all day, well, for
> several months actually.
>
> I think I have pretty simple requirements. For any given node, I want
> to be able to set a series of variables and include a set of classes,
> based on three different aspects of a node, being physical location,
> operating system, and function. If I try and do this with classes, I
> find that variables set in a class included from a node, are not
> visible to other classes included from that node.
>
> node 'node1.fr.xxx.com' {
> include facility::sjc
> include ldap::client
>
> }
>
> In this example, variables defined in facility::sjc are not visible in
> ldap::client (in this case, it would be the IP address of the local
> LDAP server).
>
> Another approach is to do everything with node inheritance, but in
> order to model these three functions, you end up with nodes with names
> like sjcDellBootServer or nycVmwareBootServer, which is just plain
> stupid.
Node names don't need to adapt to inheritance's logic.
You can do something like:
node sjc {
ldap_server="10.10.10.10"
}
node 'node1.fr.xxx.com' inherits sjc {
include ldap::client
}
When using nodes' inheritance the only real thing you've to care about
is to define variables BEFORE including any class.
So at the end it's better to include classes only in the node that
defines your host nad never in the "intermediary" nodes that can
represent facilities, networks or whatever.
On the other way, this also should work, if you want to define your
variables in a class:
class ldap::client {
include facility::sjc
do_something with "${facility::ldap_server}" in this class
BUT if you need to use "${facility::ldap_server}" in a template you
should reassing it to a local variable (dunno if the problem is the
colon or whatever I just found the problem and made a quick fix with
somehting like):
$my_ldap_server="${facility::ldap_server}"
and use $my_ldap_server in the template.
}
I'd avoid to use inheritance in the included class (facility::sjc
should not inherit anything)
Dunno if I've been clear with this example. Hope it helps
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: using puppetforge modules
> I think the modules should be written so that they assume they are > named after what they are in forge. I don't think this is a good idea, if I've understood it fully. IHMO, modules in the forge should be, in the long term, interoperable and possible interchangeable. I should "include apache" in my nodes, as always, whatever the apache module is, and I think it's really a bad thing to be have something like "include example42-apache" and then be forced to change that on all my nodes (and all the references/requires to it) when I want to switch to the apache module of someone else. But most of all, I agree with what David says about autoloading. I find absurd the idea of having classes called with the name of the author and not the sole name of the application. Ready to change my opinion, still, if given some good motivations. my cent al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: firewall type
The firewall type is an experimental feature I was pondering about. It's supposed to work as the monitor and backup types in Example42 modules, that try to standardize the way you can define what to backup and monitor in a module, whatever the module(s) you may use for that. But, contrary to them, there's not yet a working implementation of the firewall type. I'm sorry for the misunderstanding. If there's is a demand for that I can try to write a sample implementation. Thanks for the notice, best regards, Al On Jun 5, 7:24 pm, Peter Berghold wrote: > I am in the process of using some of Example 42's modules and ran into a > small snag. Quite a few of them call out for a "firewall" type which does > not exist for puppet out of the box (unless i'm missing something.) > > It's not immediately apparent to me as to where to get this type, which I > assume is a plugin. Anybody steer me in the right direction? > > -- > Peter L. Berghold > Owner, Shark River Technical Solutions LLC -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Using a set of recipes to build stuff from source...
On 19 Mag, 22:17, Peter Berghold wrote: > On Wed, May 19, 2010 at 4:08 PM, Steven VanDevender wrote: > > > P > > > You're probably going to be better off making custom RPM packages for > > things that you want to have locally-built, place them in a local > > repository that your systems are configured to access, and then using > > the Puppet "package" resource type to install them. > > I thought that as well, but didn't really want to just yet. > > If I go that route I guess it will mean I'll have to get around to doing > something I've been putting off.. I've been planning to build a custom yum > repository but that was not going to happen right way. You might find interesting (also to see how to manage dependencies among different execs) the custom define I made to manage downloads of tarballs, extract and compilation / installation commands: netinstall define http://git.example42.com/?p=example42modules/.git;a=blob;f=common/manifests/defines/netinstall.pp an example of usage: http://git.example42.com/?p=example42modules/.git;a=blob_plain;f=mailscanner/manifests/classes/netinstall.pp Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppetcamp
On 18 Mag, 19:26, Brice Figureau wrote: > Hi Alessandro, > > On 17/05/10 10:27, Al @ Lab42 wrote: > > > About the PuppetCamp, it would be nice, as "consolidated tradition", > > to arrange a meetup at least the evening of 26th of May for who is > > already at Ghent. > > I'll be in Ghent around 4PM on the 26th, so that'd be great to > meet/eat/drink (choose the ones you want). Great Brice! I shoould arrive at the Eden Hotel (mid way between town's center and the Camp place) around 6PM. For me it's ok to arrange for dinner somewhere downtown, we can go to the place suggested by RIP or wherever... Someone else wanna join? Someone is going to stay at Eden Hotel? cu soon al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Time is running out to register for Puppet Camp Europe in Ghent, Belgium May 27-28th
> > Luke Kanies > > Jeff McCune > > Scott Campbell > > Markus Roberts Too bad that Dan (Bode) is not in the bunch... :-) For the people unsure if it's worth the case to partecipate I can say that the previous Puppet Camp has been a totally enjoyful, interesting, inspiring and enlightening experience. Really something that a Puppeteer, or anyone somehow involved in systems operations, can't miss. my2c Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppetcamp
About the PuppetCamp, it would be nice, as "consolidated tradition", to arrange a meetup at least the evening of 26th of May for who is already at Ghent. Any reccomendation from belgian natives about pubs or places good for the gathering? Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppet-module-apache
> >http://github.com/camptocamp/puppet-apache > >http://github.com/wesabe/puppet-apache2 > >http://github.com/puppet-modules/puppet-apache > >http://github.com/simpsonjulian/puppet-apache-ubuntu > >http://github.com/ohlol/puppet-apache > or the one athttps://labs.riseup.net/code/projects/shared-apache For sake of completeness I'd add my own module to the list: http://git.example42.com/?p=example42modules/.git;a=tree;f=apache It's not the most complete or evoluted of the bunch but it has its own points, IMHO. In any case what I find most important is to define a common naming for defines that create virtualhosts and general .conf files so that, whatever the apache module used, there's a common way to manage its configuration's fragments. Apache is the typical module that is often referenced by other modules, right in the definition of a configuration piece that provides the web access information for an application. Since I'm almost convinced that people will keep on doing their own apache modules and there will hardlly be a monstre module good for every use (I personally find, for example, totally unfit to debianize the apache setup on a not debian breed: IMHO a puppet module should strictly follow the OS guidelines, directory's structure and practices) I would concentrate the efforts in defining "common interfaces" so that in an application module I can use always the same syntax to manage its apache configuration file. my2c al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: multiple OS support conventions?
My approach to manage different OS is similar to the ones suggested
before.
With these basic buidelines:
- When differences among OS are rather substancial, include specific
subclasses:
case $operatingsystem {
debian: { include apache::debian }
ubuntu: { include apache::debian }
default: { }
}
- When differences are just packages names, config file paths and so
on, managge differences in a specific params subclass where interla
variables are defined accoring to the OS:
class apache::params {
# Basic settings
$packagename = $operatingsystem ? {
freebsd => "apache20",
debian => "apache2",
ubuntu => "apache2",
default => "httpd",
}
$servicename = $operatingsystem ? {
debian => "apache2",
ubuntu => "apache2",
default => "httpd",
}
$username = $operatingsystem ? {
debian => "www-data",
ubuntu => "www-data",
default => "apache",
}
$configfile = $operatingsystem ?{
freebsd => "/usr/local/etc/apache20/httpd.conf",
ubuntu => "/etc/apache2/apache2.conf",
debian => "/etc/apache2/apache2.conf",
default => "/etc/httpd/conf/httpd.conf",
}
$configdir = $operatingsystem ?{
freebsd => "/usr/local/etc/apache20",
ubuntu => "/etc/apache2",
debian => "/etc/apache2",
default => "/etc/httpd/conf",
}
$documentroot = $operatingsystem ?{
debian => "/var/www",
ubuntu => "/var/www",
suse=> "/srv/www",
default => "/var/www/html",
}
}
...
In the above examples my "default" is RedHat/Centos, but it should be
better to explicitely define them.
- Classic Package-Service-ConfigFiles cases are manage in an unique
class:
class apache {
require apache::params
package { apache:
name => "${apache::params::packagename}",
ensure => present,
}
service { apache:
name => "${apache::params::servicename}",
ensure => running,
enable => true,
pattern => "${apache::params::servicepattern}",
hasrestart => true,
hasstatus => true,
require => Package["apache"],
subscribe => File["httpd.conf"],
}
file { "httpd.conf":
# mode => 644, owner => root, group => root,
require => Package[apache],
ensure => present,
path => "${apache::params::configfile}",
}
case $operatingsystem {
debian: { include apache::debian }
ubuntu: { include apache::debian }
default: { }
}
if $backup == "yes" { include apache::backup }
if $monitor == "yes" { include apache::monitor }
if $firewall == "yes" { include apache::firewall }
}
- Generally I prefer to avoid defining / setting owners/permissions on
files I leave them to the standards provided byy the relevant
packakes...
My 2c
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: LF complete recipe bundle
> Besides the execellent example42 stuff, there's also my (almost) > complete configuration available at > > http://projects.reductivelabs.com/projects/puppet/wiki/Complete_Confi... To hear this from the Father of Puppet Modules Collections is a great honour :-) Really hope to meet you, and other public ModuleSets creators, at the PuppetCamp, David. Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: London meetup during Training days
London is calling, wednesday 31 is approaching... where and at what hour are we going to meet up? Londoners decide... possibly not too far from County House, Conway Mews. Looking forward to live the feeling of a british pub :-) On 3 Mar, 21:46, Julian Simpson wrote: > The Green Man was our local until I left $DAYJOB last Friday. Should be > fine on a Wednesday unless we have a huge group. > > On 3 March 2010 17:21, Paul Nasrat wrote: > > > > > On 3 March 2010 17:11, Dan Bode wrote: > > > > On Wed, Mar 3, 2010 at 2:37 AM, Al @ Lab42 wrote: > > > >> Hei all, > > >> In London, UK from March 29 to April 2 there are 2 Puppet training > > >> classes: > > >http://reductivelabs.com/training/london-puppet-training/?x_lf_kt=2&_... > > > >> I'm personally seriously evaluating the possibility to attend the > > >> developer one, the 1st and 2nd, but in any case considering the active > > >> Puppet London scene and this specific occasion, it would be nice to > > >> organize a meetup in those days. > > >> The idea has been raised on IRC and can be better discussed here... > > >> Who is interested? > > > > I'm in. > > > You're only invited if you come bearing goodies ;) > > > > Wednesday is good for me. > > > Fine, Wednesday it is. Guess that's the end of the one course and pre > > developer course. I'll have to go scouting. ISTR us doing The Green > > Man, Riding House St which is a Cider pub before. Else can find some > > decent real ale pubs in the area that have space. > > > Paul > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- > Julian Simpson > Software Build and > Deploymenthttp://www.build-doctor.comhttp://twitter.com/builddoctor -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Possible variables to use with templates
You can have variables provided by facter (run the command facter on an host to see its variables) and define your custom variables, with extreme care to how they are scoped in puppet. http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#variable-scope This article well explains Puppet and variables scoping: http://about.digg.com/blog/master-puppets-2-speaking-language Read also here http://reductivelabs.com/trac/puppet/wiki/PuppetTemplating Al On Mar 11, 7:44 pm, Smain Kahlouch wrote: > Hi everyone, > > I guess the question has been asked a million times. > I'm a beginner in puppet and i would like to know where i can find a > list of possible variables to use the templates. > > Thanks for your help, > Grifith -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: London Puppet Training - Early-bird rate expires March 15th
Don't forget another good reason to be there... a Puppet Meetup in London, probably Wednesday the 31st of March. On Mar 11, 6:06 am, scramble wrote: > Hi All - > > Early registration is still available for Puppet Training in London: > > Puppet Master Training: March 29-31st: < March 16th = £1,495, > > >March 15th = £1,595. > > Puppet Developer Training: April 1st & 2nd: < March 16th = £895, > > March 15th = £995. > > Sign up Here to reserve your seat: > http://www.regonline.com/Checkin.asp?EventId=813907 > We're about 3/4 full at this point so still have some room. > > Becoming a Puppet Master - 3 Days: > Puppet Training consists of 3 days of hands-on training performed by a > Reductive Labs Puppet professional. Attendees will be taught the > principles and best practices of Puppet in a series of lectures and > labs.This training is ideal for those who want a Puppet jumpstart. > Newer members at an organization already using Puppet, or experienced > sysadmins wanting to bring Puppet into their team will get everything > they need to deploy solutions. > > Topics covered include: > > * Configuring Puppet and Puppetmaster > * Resource Types and the Resource Abstraction Layer > * Virtual Resources, Exported Resources and Stored Configs > * Meta-parameters, Dependencies and Events > * Classes, Modules and Definitions > * Tags and Environments > * Puppet Language Patterns and Best Practices > > Puppet Developer Curriculum - 2 Days: > This is an advanced course for those Puppet users who are interested > in developing skills and learning best practices for creating their > own custom Resource Types and Modules. > > * Introduction to Ruby for Puppet > * Advanced Function and Fact development > * Resource Type and Provider development > * Testing practices and RSpec for Puppet > > Looking forward to seeing you there. Any questions? Need lodging > recommendations? Email me at sc...@reductivelabs.com or call at > 1.503.805.9065. > > Best, > Scott C. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: RFC: A generic Monitor module
On Mar 9, 3:58 pm, Michael DeHaan wrote:
> On Tue, Mar 9, 2010 at 5:57 AM, David Schmitt wrote:
> > On 3/9/2010 10:52 AM, Al @ Lab42 wrote:
>
> >> Good morning all,
> >> lately I've tested a bit the concept of generic modules used to manage
> >> typical inter-node functions like Monitor, Backup and Firewall.
> >> My point and goal is to able to use in a module a class like the
> >> following that can manage the application monitoring indipendently of
> >> the actual monitoring software used and even of the same module used
> >> for the same software:
>
> >> class apache::monitor {
> >> monitor::port {
> >> "apache_port":
> >> proto => "tcp",
> >> port => 80,
> >> enable => true,
> >> }
>
> >> monitor::process {
> >> "apache_process":
> >> name => $operatingsystem ? {
> >> ubuntu => "apache2",
> >> debian => "apache2",
> >> default => "httpd",
> >> },
> >> enable => false,
> >> }
>
> >> monitor::plugin {
> >> "apache_plugin":
> >> name => "apache",
> >> enable => true,
> >> }
>
> >> }
>
> >> In order to make the above possible, it's needed a meta-module like
> >> what I've started to write here:
>
> >>http://git.example42.com/git/?p=example42modules/.git;a=tree;f=monito...
>
> > Oh, sweet! Great idea :-)
>
> > One quick nit on monitor::plugin: the current design would require having
> > the same name for plugins in collectd and munin, which would preclude
> > implementation-independent monitoring.
>
> > The two solutions I see here is either create a implementation-specific name
> > mapping (e.g. in defines/plugin.pp) or use monitor::plugin::{munin
> > ,collectd} directly. The latter would be less flexible and require moving
> > the "if $monitor_collectd == "yes" {" into the specific defines.
>
> > I'll try to take a deeper look later today.
>
> > Best Regards, David Schmitt
> > --
>
> I'm wondering if this might be more seamless if done as a system of
> monitoring types and providers?
>
> i.e. we have the nagios stuff in core now, but if we had a generic
> 'monitor' type with a nagios provider, other provider, etc...
>
> (We've been wanting to move some of the nagios stuff out of core
> anyway, so it could be rev'd seperately from Puppet)
>
> One catch is that it's initially more effort, but might make things
> simpler on the end user side (no variables to set, etc).
>
> --Michael
That's interesting.
Probably something more integrated in Puppetland would manage better
the flow and conversion of variables from general monitor definitions
to specific calls for different monitoring software.
And moreover it would be more easily integrated into users' modules.
I also think that it's important to keep abstraction (in your own
application XYZ module you define what to monitor, without the need to
know or decide what you use for monitoring) and have the possibility
of extending the base monitor defines (or whatever kind of meta-
objects) to manage singularities and specific settings.
Another important point IMHO is to keep the possibility of choosing
different monitoring tools AND use different implementations (module,
in this case) for the same tool (ie, manage Nagios with custom
templates and static files, without using Nagios types).
Al
Lab42
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: RFC: A generic Monitor module
On Mar 9, 11:57 am, David Schmitt wrote:
> On 3/9/2010 10:52 AM, Al @ Lab42 wrote:
> > Good morning all,
> > lately I've tested a bit the concept of generic modules used to manage
> > typical inter-node functions like Monitor, Backup and Firewall.
> > My point and goal is to able to use in a module a class like the
> > following that can manage the application monitoring indipendently of
> > the actual monitoring software used and even of the same module used
> > for the same software:
>
> > class apache::monitor {
> > monitor::port {
> > "apache_port":
> > proto => "tcp",
> > port => 80,
> > enable => true,
> > }
>
> > monitor::process {
> > "apache_process":
> > name => $operatingsystem ? {
> > ubuntu => "apache2",
> > debian => "apache2",
> > default => "httpd",
> > },
> > enable => false,
> > }
>
> > monitor::plugin {
> > "apache_plugin":
> > name => "apache",
> > enable => true,
> > }
>
> > }
>
> > In order to make the above possible, it's needed a meta-module like
> > what I've started to write here:
> >http://git.example42.com/git/?p=example42modules/.git;a=tree;f=monito...
>
> Oh, sweet! Great idea :-)
>
> One quick nit on monitor::plugin: the current design would require
> having the same name for plugins in collectd and munin, which would
> preclude implementation-independent monitoring.
>
> The two solutions I see here is either create a implementation-specific
> name mapping (e.g. in defines/plugin.pp) or use monitor::plugin::{munin
> ,collectd} directly. The latter would be less flexible and require
> moving the "if $monitor_collectd == "yes" {" into the specific defines.
Yep, good point.
Actually I don't even like a "monitor type" called plugin, since is
not related to something to monitor (port, process, host or whatever).
It's intended as a shortcut to quickly include the relevant plugin, if
any, of a monitoring software. And *generally* the name of the plugin
is the name of the application.
In any case, generally speaking I'd prefer to keep the monitor define
as much independent as possible and abstract from the actual
monitoring tool, so in this case I'd prefer the first solution,
Ciao
Al
Lab42
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] RFC: A generic Monitor module
Good morning all,
lately I've tested a bit the concept of generic modules used to manage
typical inter-node functions like Monitor, Backup and Firewall.
My point and goal is to able to use in a module a class like the
following that can manage the application monitoring indipendently of
the actual monitoring software used and even of the same module used
for the same software:
class apache::monitor {
monitor::port {
"apache_port":
proto => "tcp",
port=> 80,
enable => true,
}
monitor::process {
"apache_process":
name=> $operatingsystem ? {
ubuntu => "apache2",
debian => "apache2",
default => "httpd",
},
enable => false,
}
monitor::plugin {
"apache_plugin":
name=> "apache",
enable => true,
}
}
In order to make the above possible, it's needed a meta-module like
what I've started to write here:
http://git.example42.com/git/?p=example42modules/.git;a=tree;f=monitor;hb=HEAD
:
Puppet abstraction module: monitor
# Written by Lab42 #
# http://www.example42.com
Licence: GPLv3
DESCRIPTION:
This modules abstracts the monitoring definitions for an host or
application, in order to add
and use different monitoring methods, without changes on the single
application modules.
It's a proof of concept that tries to provide:
- a common interface for different implementations of monitoring logic
tools
- an unified syntax for monitoring resources able to adapt to
monitoring modules from different authors
- a standard way to define what an application or an host needs to be
monitored
Everything in this module is under discussion and open to
redefinition,
the goal is to prove that the concept and the implementation work
seamlessly and
to define standards accepted by the Puppet community, that can make
things this work:
class apache::monitor {
monitor {
"$fqdn_apache_port":
type=> "port",
proto => "tcp",
port=> 80,
address => $ipaddress,
}
monitor {
"$fqdn_apache_process":
type=> "process",
name => $operatingsystem ? {
ubuntu => "apache2",
debian => "apache2",
default => "httpd",
},
}
}
USAGE:
# On the HOST to be monitored:
# set the variable: $monitor=yes
# set the variable: $monitor_=yes
include monitor::target
# On the monitoring SERVER:
# set the variable: $monitor=yes
# set the variable: $monitor_=yes
include monitor::server
# If you have different monitoring servers:
# set the variable: $monitor_nagios=yes
include monitor::server::nagios
# On the APPLICATIONS module to be monitored:
include apache::monitor # Monitor apache Automatically included
if $monitor=yes
Where you can have something like the class apache::monitor seen
before.
DEPENDENCIES:
This is a meta-module that needs dependencies according to the modules
you use.
You must have storeconfigs enabled.
You generally need the "common" module and all the prerequites for the
modules related to monitoring
applications you decide to use.
--
I've tried to verify if this approach can effectively work with
different software (tried with munin, collectd and nagios) and
different modulesets (tried to integrate, for testing, DavidS',
Immerda, Camptocamp, RiseUp's modules) .
An example of the latter is here:
http://git.example42.com/git/?p=example42modules/.git;a=blob;f=monitor/manifests/nagios.pp
the POF works, even if I see many open issues that I would like to
discuss here, with module-sets writers and generally whoever is
interested is some form of interoperability between modules.
First of all for my is important to find agreement on the general
concept (an unified, standard, way to monitor applications in
different module sets).
The implementation, my "alpha" module class, the same syntax and
naming conventions (the arguments needed to monitor different
resources) and the collectors structure (how to convert a generic
monitor define to a specific monitoring module by a specific module-
sets), are completely development stage and under discussion.
And is also under discussion if this same approach can work seamlessly
and cleanly.
Since I think this matter can relate also to the module-forge topic,
for me it would be important to have opinions and feedback from module
writers lik
[Puppet Users] Re: London meetup during Training days
> > > > I'm in. Great! > > Wednesday is good for me. > > Fine, Wednesday it is. Guess that's the end of the one course and pre > developer course. I'll have to go scouting. ISTR us doing The Green > Man, Riding House St which is a Cider pub before. Else can find some > decent real ale pubs in the area that have space. +1 for Wednesday. Seems just the right day. al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] London meetup during Training days
Hei all, In London, UK from March 29 to April 2 there are 2 Puppet training classes: http://reductivelabs.com/training/london-puppet-training/?x_lf_kt=2&_x_lf_kvid=7b51e3db-8ab0-4594-bcd8-3f84596a3748 I'm personally seriously evaluating the possibility to attend the developer one, the 1st and 2nd, but in any case considering the active Puppet London scene and this specific occasion, it would be nice to organize a meetup in those days. The idea has been raised on IRC and can be better discussed here... Who is interested? What dates do you suggest? (for me better wed, thu or fri, but I suppose more or less informal and restricted pub meetups can take place all over the week) Hope to be in London at the end of the month and have a good beer with bold puppeteers. Cheers Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Combining our experience into a larger, common module repo
This thread is music for my hears...
I'm sorry to have missed the list in the last days, and I take the
occasion to reopen this thread it in order to avoid that also this one
fades forgotten as various other threads, in the past, about modules
standards, naming conventions, metadata and interoperability.
I'm glad that there's new drive, directlty from RL, on this topic and
I'm definitively willing to contribute in some way.
So, even if this might not be the right place and time, I'd like to
throw in some points.
I've just recently started to extend multiOS support in my modules and
I'm still trying to figure out the best way to handle that but one
thing is sure: a way to routinely test modules behavious on different
OS and different Puppet versions is necessary.
I wonder (or, better, ask to James) if Puppet continuos integration
(
http://reductivelabs.com/trac/puppet/wiki/Development/PuppetContinuousIntegration
) relates only to Puppet building and its tests or can (will) be
somehow applied on Puppet runs on a set of Puppet Modules.
Besides this, I think that big isses in interoperability about
different sets of modules raise in the use of custom types, different
approaches to the same problem, and different ways to handle cross-
modules functions, such has monitoring, backup, firewall management
and so on, that generally work well only inside the same set of
modules.
I like, and have played a bit with, the idea of using "wrappers" with
(erm... ) standard naming conventions to manage common activities.
Something like:
A "wrapper" define called "Config" to manage files' inline
modifications using different methods ( something like:
http://www.example42.com/browser/common/manifests/defines/config.pp )
A wrapper module/define called "Monitor" to manage monitoring of nodes
(and services/ports/file systems...) using different monitoring tools
(according to custom needs) so that in your (standard) module you just
define what you want to Monitor with a standard naming convention,
using then the Monitor method you prefer ( some embrional attempts
here: http://www.example42.com/browser/monitor/manifests/init.pp )
Similar wrappers can be used for Backup or Firewall and so on. I Love
the idea to have, for example, an Apache module where is wrtitten: I
want to Backup /var/www/html (or whatever) AND make the Firewall open
input port 80 without caring what backup system I use and how I manage
my firewalls (that is done and customized in the backup and firewall
modules...)
Dunno if I made the point.
Last but not least, I would like to have a shared modules environment
where I can choose the module I want, for the same application, among
alternatives.
I'm costantly looking at how others do theirs modules and I always
learn a lot from them (DavidS, Camptocamp, Vulcane's PuppetManaged to
name a few), still most of the times, when I wanted to import and use
modules made by others, I found myself rewriting them in order to
follow my own way of thinking, my knowledge (or lack of) and style to
approach the same problem.
This is probably the same for eveybody, so I don't think there should
be just ONE approach in a module for an application, but a base
structure, and different alternatives/defines/subclasses to choose
from.
But hey, I know, I'm putting too much inside this pot, big results are
achieved in small steps, so Michael and RL, drive the path, do as
you've said ("no need to design up-front on the list") and tell us
what we can do.
Alessandro
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: ssh::auth version 0.3.2 released
The correct link is http://www.example42.com Before there was a redirect to http://www.example42.com:811 that it doesn't work if you are behind a proxy. I've finally placed a reverse proxy to avoid such a problem. Thanks, Al (the commit with your ssh:auth is not yet online) On 2 Gen, 16:49, Andrew Schulman wrote: > > Andrew, > > I'd like to integrate your ssh::auth in my module set > > (www.example42.com), hope you don't mind. > > I'm going to change the license of my modules from Creative Commons to > > GPL3 in order to be more free to integrate other users modules > > released under GPL3. > > Sure, I have no objection. I can't get your site to come up just now, so I'm > not sure what's there, but you're welcome to 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: ssh::auth version 0.3.2 released
Andrew, I'd like to integrate your ssh::auth in my module set (www.example42.com), hope you don't mind. I'm going to change the license of my modules from Creative Commons to GPL3 in order to be more free to integrate other users modules released under GPL3. Best regards Al On 29 Dic 2009, 15:49, Andrew Schulman wrote: > I've uploaded version 0.3.2 of ssh::auth > tohttp://reductivelabs.com/trac/puppet/wiki/Recipes/ModuleSSHAuth. This > release fixes a couple of bugs since version 0.3: > > * Fix parser error in ssh_auth_namecheck > * Fix wrong $home when user is specified separately for a client or server > > In addition, the documentation now makes clear that ssh::auth won't manage > the users' $home/.ssh directories; the site admin has to do that. > > ssh::auth is a Puppet module that provides centralized creation, > distribution, and revocation of ssh keys for users. Features: > > * Each user may have one or more ssh key pairs, centrally created on the > keymaster and distributed to servers and clients. > > * Each key pair may be installed onto any set of clients, and enabled for > authentication as any user(s) on any set of servers. > > * Keys may have login options set as in authorized_keys(5), e.g. to force > certain commands to run or limit port forwarding. > > * Keys can be uninstalled or revoked, either manually or automatically at > given intervals, and new ones automatically created and distributed. > > Installation is easy, as it's just one file. > > ssh::auth aims to provide a complete solution for managing ssh keys for > users, with a well-defined and -documented interface. There's a comparison > to the other ssh-related tools available in Puppet > athttp://reductivelabs.com/trac/puppet/wiki/Recipes/ModuleSSHAuth#compa... > . > > Andrew. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Modules metadata standards
On 21 Dic, 01:50, James Turnbull wrote:
> 2009/12/21 Julian Simpson :
> > 2009/12/18 Al @ Lab42 :
> > [snip]
> >> Now, as a user, I think that it is important to know how to start to
> >> write metadata files: format and minimal required parameters.
> >> A final (?) decision is not to be rushed, but an indication of the
> >> format and on some basic parameters that won't be changed for sure is
> >> definitively welcomed.
> >> If from this thread comes out an "officially Puppet complant" example
> >> of a metadata file I'm an happy guy.
>
> > +1.
>
> > Happy to agree the above. I'd rather specify less and get some broad
> > agreement on what makes the minimal and official/community compliant
> > metadata, than try and pin down every detail. I'd assumed that the
> > metadata would be in Ruby code, but equally happy with JSON or YAML.
>
> For those of you who haven't seen the module metadata this is the
> commit (in master and so scheduled for Rowlf not 0.25.2):
>
> http://github.com/reductivelabs/puppet/commit/adc211ad191568e84eb3e1f...
>
> Regards
>
> James Turnbull
>
> --
> Author of:
> * Pro Linux System Administration (http://tinyurl.com/linuxadmin)
> * Pulling Strings with Puppet (http://tinyurl.com/pupbook)
> * Pro Nagios 2.0 (http://tinyurl.com/pronagios)
> * Hardening Linux (http://tinyurl.com/hardeninglinux)
In order to have a real *correct* example of how a json metadata file
should be, according to what is written in
http://github.com/reductivelabs/puppet/blob/adc211ad191568e84eb3e1f618f1cbf78df95ba9/lib/puppet/module.rb
, I ask to the lurking Ruby and Puppet Gurus if something like what
follows could be a correct example of a metadata file.
The name of the file is MODULEPATH/metadata.json
The content (please review/fix):
{"apache": {
"source": "git://www.example42.com/example42puppetinfrastructure",
"author": "Alessandro Franceschi",
"version": "0.1.3",
"license": "GPL3",
"puppetversion": "0.24",
"summary": "Standard Apache module",
"description": "This module can be used for basic Apache
management",
"project_page": "http://www.example42.com";,
}}
If we wanted to implement some of the suggestions people have made on
metadata info is something like this suitable (check syntax and
logic)? :
{"apache": {
"source": "git://www.example42.com/example42puppetinfrastructure",
"author": "Alessandro Franceschi",
"version": "0.1.3",
"license": "GPL3",
"puppetversion": "0.24",
"summary": "Standard Apache module",
"description": "This module can be used for basic Apache
management",
"project_page": "http://www.example42.com";,
"dependencies": {
"native_types": [ "replaceline", "configfile" ] ,
"parsec_functions": "" ,
"modules": "" ,
"facter_plugins": "" ,
}
"tested": {
"centos": [ "4", "5" ] ,
"solaris": "5.10" ,
}
}}
And, if we wanted to give more info on classes and defines provided
with the module there should be detail for each class on the required/
optional parameters and eventually the same class dependencies (it's
not rare the case of a module with simple classes with no dependencies
and more complex classes with custom deps).
I suppose there's still much to talk and code around, but it would be
nice to have confirmations on this metadata format and maybe on some
of the proposed details.
Some references for Json:
http://www.json.org/
http://www.json.org/example.html
http://www.ietf.org/rfc/rfc4627.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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Proposals for modules naming conventions
> >>> 8- PROPOSAL (don't think it will be widely liked): Variables names
> >>> needed for module configuration (the ones used in templates, for
> >>> example) should have a my_ prefix, in order to easily distinguish
> >>> them
> >>> from fact variables.
>
> >> Glad you retracted this. :)
>
> > Still I'm wondering how to name variables that are not related to a
> > single class but are somehow more general.
> > I know that it's a questionable approach, but I still find variables
> > as $my_zone (indicating basically the network where the node is, or
> > anyway, a grouping logic) or $my_role (indicating the function of the
> > node, such as webserver, dabasase ...) very useful to manage different
> > files or variables sets for different cases.
> > How am I supposed to call them? Should I stop to use them? Even using
> > external nodes you group nodes according to similar logics and besides
> > setting variables you may want, for example to source different files
> > accoring to different groups.
>
> I'm not really sure what you mean.
>
> On this note, I believe we're planning on adding scoped variables to
> the external node interface in the near future -- you could set
> '$apache::port' in your external node tool, and your 'apache' class
> would automatically get '$port' set in its scope. Does that cover
> what you want, or is it unrelated?
It's not related (my case is for variables not directory related to a
module, that I use to group hosts according to function (role) or
network (zone) and are useful for setting groups of other variables or
providing different configurations according to zone/role) but it's an
interesting news.
> >>> So, the point of this post is to know if there has been some
> >>> agreement
> >>> on naming standards and eventually to stir the discussion about it.
> >>> My general idea is that if the community doesn't find a general
> >>> agreement, a suggested standard should come from Reductive Labs, so
> >>> that whoever is interested in sharing modules (for reusage) knows
> >>> how
> >>> to behave and, possibly, users can more easily use and integrate
> >>> modules picked from different repositories.
>
> >> I think this is a relatively good starting point. There are a bunch
> >> of areas that it doesn't yet cover -- e.g., the whole problem of
> >> managing modules written by others, such as what to do when two
> >> people
> >> have produced a module with the same name. A lot of those will come
> >> out as the module forge starts to develop.
>
> > Yes, the possibility to integrate and/or exchange modules from
> > different sources, or to plug them seamlessly in an existing
> > infrastructure is something to work on.
> > For example now if you get modules from a source, you inherit some
> > custom choices (for example the monitoring logic) that won't work
> > without modification with modules from other sources.
> > I was thinking if it's worth to agree on some standard for typical
> > cross-node operations such as, for example, monitoring or backup.
>
> > I imagine at least 2 approaches:
> > 1- Standard named subclasses
> > Something like an httpd::monitor class, that is included where
> > necessary and doesn't inherit anything, so that it can be somehow
> > independent from different httpd classes, where you define what and
> > how to monitor your service. What is inside this class can change
> > according to custom logic, coherent in your puppet infrastructure, but
> > at least you know that here and only here you find all the stuff
> > related to monitoring, so you can adapt it to your monitoring layout
> > and needs.
> > Something similar might be done for example in httpd::backup to define
> > and manage backup logic
>
> > 2- Custom types with standard names
> > I'd love to place in my modules a sort of "custom but with standard
> > name" type "Backup", that defines what to backup, whatever my backup
> > system is. Something that would look like:
> > backup {
> > "wwwdata":
> > path => $operatingsystem ?{
> > default => "/var/www/html",
> > },
> > }
>
> > what the backup define does is then left to custom approaches
> > according to the backup methods and tools used.
> > Something like this can be expanded for other needs, such as auditing
> > and monitoring.
>
> I like both of these, but given how rarely it's come up for us yet,
> I'm more comfortable letting people experiment with it for a while and
> try to extract a standard from a bunch of practice, rather than guess
> how it will go.
You are probably right, even if I would like to receive some opinions
and suggestions from other modules writers.
I find somehow crucial the possibility to somehow find
"interoperability standards" between module sets in order to ease
integration and incorporation of other modules in a custom set.
> > A rushed down example (I feel like also this won't be liked by
> > many :-) :
>
[Puppet Users] Re: Proposals for modules naming conventions
On 18 Dic, 20:46, Luke Kanies wrote:
> On Dec 17, 2009, at 8:15 AM, Al @ Lab42 wrote:
>
> > Hallo *,
> > at the Puppet Camp there has been some discussion about modules
> > standards and naming conventions.
> > I might have missed some relevant bits in the last months of personal
> > absence from the list so I'm not sure if this topic has evolved or has
> > been discussed more deeply.
>
> > I take this occasion to sum up what seem somehow the community
> > standards and propose something else for, simply, the conventions we
> > might try to agree on class names.
> > I take as reference what is written
> > inhttp://reductivelabs.com/trac/puppet/wiki/ModuleStandards
> > introduction what are my personal proposals
>
> It's great that you've started this discussion. We're finally making
> progress on enhancing the modules, both from the perspective of the
> language (adding metadata, etc.) and from the management perspective
> (Bruce Williams is leading the team working on a module forge).
>
> > COMMUNITY "STANDARDS" SUM-UP (?)
>
> > 1- a class for an application, sharing the same name. (IE: apache
> > (not httpd) for managing Apache)
> > Still I wonder why I (and many) use ssh instead of openssh :-)
>
> > 2- distinct names for client and server, where applicable (IE:
> > samba::client , samba::server)
>
> I agree with both of these.
>
> > 3- FROM WIKI: Operating system differences should be specified in
> > variables in a case at the start of the module, as follows:
> > class ssh::server {
> > case $operatingsystem {
> > "freebsd","openbsd": {
> > $sshservice = "sshd"
> > }
> > debian: {
> > $sshservice = "ssh"
> > }
> > }
>
> I'd love to see this broken out into a constant-like functionality in
> the class. I think rowlf or the release after it will support class
> attributes again (yay!), and this should work at that point:
>
> class ssh::server($sshservice = $operatingsystem ? {["freebsd",
> "openbsd"] => "sshd, default => "ssh" }) { ... }
>
> Or something similar. You're using logic, so it's not trivially
> introspectable like a straight constant would be, but at least you've
> declared that the class uses this attribute and that it's calculated
> rather than set internally.
That's interesting, +1
> > > # use a constant title to facilitate stable relations
> > service { "ssh::server":
> > name => $sshservice,
> > ensure => running,
> > enable => true,
> > }
> > }
>
> > I personally prefer something like (not avoid unnecessary internal
> > variables in modules):
> > class ssh::server {
> > service { "ssh::server":
> > name => $operatingsystem ? {
> > debian => "ssh",
> > default => "sshd",
> > }
> > ensure => running,
> > enable => true,
> > }
> > }
>
> > but that affects the class internals and is not relevant for the name
> > itself.
>
> I think these are fine solutions in the short term, but they're more
> an indication of poor expressiveness in the language than they are a
> real solution. I want to be able to specify, at parse-time, which
> platforms a given class works for, and we're now at the point where we
> can start to add that ability. For instance, this syntax doesn't work
> right now but it could now be added relatively easily (on top of the
> code for #2596[1]:
>
> class apache supports($operatingsystem => [solaris, debian]) { ... }
>
> There's obviously a lot of work to do to figure out what you want to
> specify and how it works. This is syntactically similar to parameters
> in definitions but functionally equivalent to our common 'confine'
> usage, so I'd like to find a way to use that term.
>
> The things I prefer about this syntax is that it's declared as data
> rather than in the logic of the class, and it's queryable at parse-
> time. This means we could, for instance, throw an exception if anyone
> tried to use the class on an unsupported platform. Of course, in most
> cases you'd want to just warn in such a case, rather than fail, but
> there are definitely cases where you'd want to fail instead.
>
> As this integrates into the dashboard and similar tools, you get even
> more power - the console for connecting a node with a class could gi
[Puppet Users] Re: Proposals for modules naming conventions
On 17 Dic, 22:04, Julian Simpson wrote: > Was there discussion on metadata for modules? I know Luke was > experimenting with that. I'd love to see what OS(es) a module has > been tested on, and what versions of Puppet. > Yes there has been discussion, that's another important point, I started this: http://groups.google.com/group/puppet-users/t/f2fdc84e423c7768 to summarize and discuss modules metadata. This and naming standards are both releant topics, for me, and maybe is better to keep them divided in order to reach, somehow, a sythesis on both. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Modules metadata standards
I would like to start a new thread dedicated to the Modules metadata discussion. At the Puppet Camp and on this list there has been discussion about this. I might have missed some bits, but afaik there's not yet a formal decision about that. So if anyone knows more, please update me. It has been discussed the modules packaging format, the metadata format and of course the metadata info to provide. In order to sum up things, and avoid repeating things already written, I've found these references on the topic: 1- GIT COMMIT "Adding additional module metadata" by Luke http://github.com/lak/puppet/commit/3896288ff56b44ae6f5e1f0c2a8adc995a458f76 This is for sure the starting point: json format, some basic parameters: :source, :author, :version, :license, :puppetversion, :summary, :description, :project_page 2- THREAD: Module Standards discussion http://groups.google.com/group/puppet-users/browse_thread/thread/66b90ee0e3a229c2?hl=en Blake Barnett proposed a yaml example such as the following, the discussion then somehow has evolved on metadata format and modules packaging but the info outlined can be interesting: module_postfix.yml --- name: postfix version: 0.1 description: Yay postfix. provides: classes: postfix, postfix::ldap, postfix::gerbils definitions: - name: postfix_spamq description: Specifies blah de blah required_parameters: - name: ensure - parameter_options: present, absent default: present optional_parameters: native_types: postfixregex dependencies: native_types: parser_functions: modules: facter_plugins: 3- THREAD: Proposals for modules naming conventions http://groups.google.com/group/puppet-users/browse_thread/thread/eb0ee0dc312d1a4 Julian Simpson suggests: "Was there discussion on metadata for modules? I know Luke was experimenting with that. I'd love to see what OS(es) a module has been tested on, and what versions of Puppet." in another post he says: " I'd like to make a proposal around module metadata, so that you could declare things like: - this module depends on others - this module works for this list of $operatingsystems - this module uses this sysadmin strategy " +1 for info about testing results for different puppet versions and OS. --- Now, as a user, I think that it is important to know how to start to write metadata files: format and minimal required parameters. A final (?) decision is not to be rushed, but an indication of the format and on some basic parameters that won't be changed for sure is definitively welcomed. If from this thread comes out an "officially Puppet complant" example of a metadata file I'm an happy guy. My 2c Al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Proposals for modules naming conventions
On 17 Dic, 20:51, Scott Smith wrote: > Al @ Lab42 wrote: > > 1- a class for an application, sharing the same name. (IE: apache > > (not httpd) for managing Apache) > > Still I wonder why I (and many) use ssh instead of openssh :-) > > Hmm, I think most of the conventions are sensible, thanks for taking the time > to summarize it all! > > On point #1 however, I kind of disagree: Technically Apache (Software > Foundation) is the > organization, and the web server is Apache HTTP Server. I do agree that > `httpd' is way too generic. > In this case I prefer to use `apache::httpd' and `apache::tomcat' etc. > > Just my opinion :) > > -scott Right point. I actually would prefer, at this point, httpd rather than apache::httpd, also because otherwise for coherency we should somehow always define the makers of the software. Maybe we could just try to make a list of possible "standardized" modules names, at least for the dubious cases: openssh or ssh? apache or httpd or apache::httpd? dashboard or puppet::dashboard or puppet::nodemanager? ;-) I can't imagine now more similar dubious cases, but surely there are. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Proposals for modules naming conventions
On 17 Dic, 17:28, David Schmitt wrote: > Hi Al, > > Welcome back, great post! > > +1, except for (as predicted) #8, where I think that the rationale > doesn't make sense, especially if one wants to start configuring modules > via facter and/or external nodes. prefixing with the module name would > make more sense for me. > > Regards, DavidS Hi David, thanks for the reply. You and Michael have definitively convinced me about variable name namings (modulename_ is surely a better prefix). I take the occasion of your reply to discuss deeper a topic that I've always found somehow controversial. Many use to say, if I've understood well, that in a puppet infrastructure there should only be variables generated by facts, that it's not a good idea to define custom variables at node's level (or using different ways to group/classify them). I can understand this if we talk about external nodes, when you can have powerful and easy ways to aggregate/define variables for nodes (and still they are not fact variables), but I still have to understand why and how it should be better to define variables necessary for your classes (for example an external server where to send syslog messages, which changed according to different servers' locations or test/prod status or whatever logic) in a fact. I find more difficult to write and control this logic in custom facts splattered in different modules, rather that in a single "infrastructural" class where all variables are defined according to custom logic and groupings, or, as I generally do, in a nodes' inheritance structure, where there are intermediate node that can define networks or geographical locations or whatever groups that are inherited by host nodes. Excuse my ignorance, if someone can enlighten and convince me on the advantages of placing the logic of a puppet infrastructure in facts, please do it. I like to redefine my beliefs :-D al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Proposals for modules naming conventions
Thanks for feedback,
> > 3- FROM WIKI: Operating system differences should be specified in
> > variables in a case at the start of the module, as follows:
> > class ssh::server {
> > case $operatingsystem {
> > "freebsd","openbsd": {
> > $sshservice = "sshd"
> > }
> > debian: {
> > $sshservice = "ssh"
> > }
> > }
> > # use a constant title to facilitate stable relations
> > service { "ssh::server":
> > name => $sshservice,
> > ensure => running,
> > enable => true,
> > }
> > }
>
> +1, that's what I use usually
>
> > I personally prefer something like (not avoid unnecessary internal
> > variables in modules):
> > class ssh::server {
> > service { "ssh::server":
> > name => $operatingsystem ? {
> > debian => "ssh",
> > default => "sshd",
> > }
> > ensure => running,
> > enable => true,
> > }
> > }
>
> > but that affects the class internals and is not relevant for the name
> > itself.
>
> I still prefer the former as OS differences are encapsulated in one place.
> This one may be better for really small differences.
Well, you generally have different values for package/service names
and configuration files paths.
When differences are wide enough (IE: apache) point 4 is definitively
the best, but in most cases I find the above variations more clear if
defined where they are used.
But this is really a matter of taste, and doesn't affect the general
logic (no need for separated modules when differences are few).
> > 5- Specific variations on the normal behaviour of an application
> > should be specified as subclasses (IE: samba::pdc or samba::ldap)
>
> How does that relate to ::server and ::client above? E.g. if samba::pdc
> implies samba::server wouldn't it be better if it was samba::server::pdc?
Ya, you're are right. If there is a samba::server there should be a
samba::server::pdc.
> > 7- PROPOSAL for general class configuration define (based on augeas or
> > other inline modificators)
> > define ssh::config ($value) {
>
> > # Augeas version.
> > augeas {
> > "sshd_config_$name":
> > context => $operatingsystem ? {
> > default => "/files/etc/ssh/sshd_config",
> > },
> > changes => "set $name $value",
> > onlyif => "get $name != $value",
> > # onlyif => "match $name/*[.='$value'] size == 0",
> > }
>
> > # Davids' replaceline version (to fix)
> > # replaceline {
> > # "sshd_config_$name":
> > # file => "/etc/ssh/sshd_config",
> > # pattern => "$name",
> > # replacement => "^$name $value",
> > # }
> > }
>
> > This define can be used in a class like
> > class ssh::eal4 {
>
> > # Cripto settings
> > ssh::config { Protocol:
> > value => "2",
> > }
>
> > ssh::config { Ciphers:
> > value => "3des-cbc",
> > }
>
> > # X11 forwarding (You MAY allow)
> > ssh::config { X11Forwarding:
> > value => "no",
> > }
> > []
> > }
>
> This makes sense, one problem with that however is that this creates a
> resource for each option. So AFAIK for augeas that means the code (opening
> the file, trying and appying changes) will be executed as many times as you
> have options.
>
> Perhaps when hashes are available using them to map (key, value) pairs to
> augeas set commands would make sense.
That's a point, but it actually doesn't affect the naming convention,
but how singular lines modifications are implemented.
At the moment I prefer to use augeas on a puppet generated file of
"augeas commands", that is served as a file resource and subscribes an
exec that runs augeas using that file as a "source" (this has the
advantage that you can use augeas on a file in an arbitrary path,
which is currently still not possibile, even if a patch on the augeas
type for this is already done and ready the the next release).
In any case, HOW you manage to get the line configured is not what I
wanted to discuss (even if this is always a very interesting and
challenging topic), I just seek for naming standards ;-)
> > 8- PROPOSAL (don't think it will be widely liked): Variables names
> > needed for module configuration (the ones used in templates, for
> > example) should have a my_ prefix, in order to easily distinguish them
> > from fact variables.
>
> Yeah, not really ;) I do however use ${APPNAME}_ or ${CLASSNAME}_ prefix for
> variables which a class treats as parameters.
I retire my proposal.
What you've written, and DavidS has confirmed, is probaly more
suitable (and it's actually what I used to do, some time ago :-! )
All the best
al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
htt
[Puppet Users] Proposals for modules naming conventions
Hallo *,
at the Puppet Camp there has been some discussion about modules
standards and naming conventions.
I might have missed some relevant bits in the last months of personal
absence from the list so I'm not sure if this topic has evolved or has
been discussed more deeply.
I take this occasion to sum up what seem somehow the community
standards and propose something else for, simply, the conventions we
might try to agree on class names.
I take as reference what is written in
http://reductivelabs.com/trac/puppet/wiki/ModuleStandards
introduction what are my personal proposals
COMMUNITY "STANDARDS" SUM-UP (?)
1- a class for an application, sharing the same name. (IE: apache
(not httpd) for managing Apache)
Still I wonder why I (and many) use ssh instead of openssh :-)
2- distinct names for client and server, where applicable (IE:
samba::client , samba::server)
3- FROM WIKI: Operating system differences should be specified in
variables in a case at the start of the module, as follows:
class ssh::server {
case $operatingsystem {
"freebsd","openbsd": {
$sshservice = "sshd"
}
debian: {
$sshservice = "ssh"
}
}
# use a constant title to facilitate stable relations
service { "ssh::server":
name => $sshservice,
ensure => running,
enable => true,
}
}
I personally prefer something like (not avoid unnecessary internal
variables in modules):
class ssh::server {
service { "ssh::server":
name => $operatingsystem ? {
debian => "ssh",
default => "sshd",
}
ensure => running,
enable => true,
}
}
but that affects the class internals and is not relevant for the name
itself.
4- FROM WIKI: Bigger operating system differences should be split out
into their respective classes:
class ssh::server::common {
service { 'ssh::server': ... }
}
class ssh::server::debian inherits ssh::server::common {
Service['ssh::server'] { name => 'ssh' }
}
class ssh::server {
include "ssh::server::$operatingsystem"
}
5- Specific variations on the normal behaviour of an application
should be specified as subclasses (IE: samba::pdc or samba::ldap)
6- PROPOSAL for service or application status (based mostly on what
I've seen around).
- If you want an application removed provide something like:
apache::absent inherits apache {
Package["apache"] {
ensure => absent,
}
}
- If you want an application stopped provide something like:
apache::stopped inherits apache {
Service["apache"] {
ensure => stopped,
}
}
- If you want an application not enable at boot time provide something
like:
apache::disabled inherits apache {
Service["apache"] {
enable => false,
}
}
7- PROPOSAL for general class configuration define (based on augeas or
other inline modificators)
define ssh::config ($value) {
# Augeas version.
augeas {
"sshd_config_$name":
context => $operatingsystem ? {
default => "/files/etc/ssh/sshd_config",
},
changes => "set $name $value",
onlyif => "get $name != $value",
# onlyif => "match $name/*[.='$value'] size == 0",
}
# Davids' replaceline version (to fix)
# replaceline {
# "sshd_config_$name":
# file => "/etc/ssh/sshd_config",
# pattern => "$name",
# replacement => "^$name $value",
# }
}
This define can be used in a class like
class ssh::eal4 {
# Cripto settings
ssh::config { Protocol:
value => "2",
}
ssh::config { Ciphers:
value => "3des-cbc",
}
# X11 forwarding (You MAY allow)
ssh::config { X11Forwarding:
value => "no",
}
[]
}
8- PROPOSAL (don't think it will be widely liked): Variables names
needed for module configuration (the ones used in templates, for
example) should have a my_ prefix, in order to easily distinguish them
from fact variables.
So, the point of this post is to know if there has been some agreement
on naming standards and eventually to stir the discussion about it.
My general idea is that if the community doesn't find a general
agreement, a suggested standard should come from Reductive Labs, so
that whoever is interested in sharing modules (for reusage) knows how
to behave and, possibly, users can more easily use and integrate
modules picked from different repositories.
My 2c
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Stuck with puppet
Hi Reno,
in puppet.conf on the client you have:
server = Asus-Vista-Box
this should be an host you can find (via hosts or dns) AND the
hostname of your server, otherwise you run into certificates problems.
I suggest to use "puppet" as servername (the default) or change things
in the followring way:
- Take the hostname of the server
- Make it reacheable from the client (eventually editind /etc/hosts)
- Remove the old client certificates. On the client: rm -rf /var/lib/
puppet/ssl
- Clean the client certificate on the server: puppetca --clean
debian.lokku.net
- Relunch puppetd -t on the client, sign the new certificate on the
server, relaunch puppetd -t
Good luck
Al
On Oct 21, 12:21 pm, Reno wrote:
> Hi, thanks for the reply.
>
> reno# puppetd --test
> warning: Certificate validation failed; considering using the certname
> configuration option
> err: Could not retrieve catalog: Certificates were not trusted:
> hostname was not match with the server certificate
> warning: Not using cache on failed catalog
>
> On Oct 20, 10:39 pm, nothings_absolute wrote:
>
> > If you run puppetd with the "--test" and "--debug" options you
> > should be able to see that resource being applied (Or not). It could
> > be that an error in one of these files will be obvious with the output
> > from running it manually with these options.
>
> > On Oct 20, 11:24 am, Renato Tuveri wrote:
>
> > > Hello a newbie here.
>
> > > The situation is that:
>
> > > 2 machine one master one client
> > > Puppet 0.24.5
>
> > > This my configuration:
>
> > > Client:
>
> > > /etc/puppet/puppetd.conf
>
> > > [puppetd]
> > > server = Asus-Vista-Box
> > > logdir = /var/log/puppet
> > > vardir = /var/lib/puppet
> > > rundir = /var/run
>
> > > master
>
> > > /etc/puppet/manifests/classes/sudo.pp
>
> > > class sudo {
> > > file { "/etc/sudoers":
> > > owner => "root",
> > > group => "root",
> > > mode => 440,
> > > }
>
> > > }
>
> > > /etc/puppet/manifests/site.pp
>
> > > import "classes/*"
>
> > > node default {
> > > include sudo
>
> > > }
>
> > > I make
>
> > > puppetca --list
> > > debian.lokku.net
>
> > > and
>
> > > puppetca --sign debian.lokku.net
> > > Signed debian.lokku.net
>
> > > But even I restart both client and master 100 times if I do:
>
> > > ls -l /etc/sudoers
> > > -rwxrwxrwx 1 root root 5 2009-10-20 17:52 /etc/sudoers
>
> > > What I did wrong?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: lunch at Google on Wednesday for Puppet Campers?
Hi Ohad, I'll come from Serrano too, so a shared car ride is welcomed. Meet you there tuesday evening or wednesday morning... Al On 29 Set, 03:12, Ohad Levy wrote: > Hi, > > I would be happy to join - Thanks Nigel :) > > if anyone needs a ride from the Serreno hotel (or nearby) , and / or want to > drive together let me know :) > > Ohad > > On Tue, Sep 29, 2009 at 1:57 AM, Nigel Kersten wrote: > > > If you're interested in coming along for lunch at Google on Wednesday > > before Puppet Camp, let me know and I'll see if we can handle the load > > :) > > > -- > > nigel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: lunch at Google on Wednesday for Puppet Campers?
I definitively would love to lunch at Google. Coming to SF Tuesday evening. We should also define some kind of meeting place&hour for the Wednesday evening meetup. I don't intend to sleep too much in the follwing days :-) Al On Sep 28, 8:40 pm, Alex Laslavic wrote: > Love to but my flight won't get in until late afternoon. Have fun. > > On 9/28/09, Nigel Kersten wrote: > > > > > If you're interested in coming along for lunch at Google on Wednesday > > before Puppet Camp, let me know and I'll see if we can handle the load > > :) > > > -- > > nigel > > -- > Sent from my mobile device > > Alex Laslavic --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Camp codefest prelude
I'm supposed to arrive at SF the evening of 29, lodging at the Serrano. At disposal for documentation and test support. cu Alessandro Franceschi > It starts as soon as you get there. > > I didn't see anyone actually set a time yet, which is sort of what I was > hoping to get out of this thread. > > Who's around, when and where? > > If there is enough interest and foreign nationals, we could just make a day > 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 For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Announcement: new web interface for puppet and more
Seems a much better name than the earlier one :-) I wanted to write something similar (in php, the only language I know) but this is one more good reason not to start with it ... Looking forward to talk about it at the camp Alessandro Franceschi Lab42 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Camp
So, it seems that a bunch of puppetmasters will be roaming around SF waiting for the Camp. I suppose we can arrange a meeting at least the evening of 30 September, but also earlier for somebody. We can define here a meeting place & hour in a sensible, recognizable, place, and then move to a restaurant, pub or whatever. Any suggestion from SF natives? Alessandro Franceschi Lab42 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: environments for several internal customers?
Philipp, a side note to avoid confusion: Macno = Al @ Lab42 There was some bug lurking in Google groups that used in this group a nick I defined for another one... Alessandro --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: environments for several internal customers?
> All what customer beta has to do is to run something like that in the > console > > puppetd -t --environment=alpha > > or to change the environment entry to alpha in /etc/puppet/puppet.conf > on the client side ! > > So there is no security in place ;-(. Well, not exactly. In order to do this he should be able to add his client hostname on the alpha environment node list (I take for granted that no specific activity is made for the default basenode), and he hasn't the privileges to do that. Actually, anyway, I used this approach in a place where the the puppet managers are few and trusted, and can even sudo to restart puppetmasterd in case of necessity. Ciao Alessandro --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: module organisation advice
Hi Rene,
if only your team manages puppet configurations, you should use only a
module to manage all the differencies.
To cope with totally different files you can to something like
class ssh {
[...]
file {
"sshd_config":
mode => 600, owner => root, group => root,
require => Package[ssh-server],
ensure => present,
path => $operatingsystem ?{
default => "/etc/ssh/sshd_config",
},
content => [ template("ssh/sshd_config-
$hostname"), template("ssh/sshd_config-$my_zone"), template("ssh/
sshd_config") ]
}
}
Some notes:
- The file is provided as as template of the module ssh, on the
puppetmaster it should stay in /module/dir/ssh/templates/sshd_config..
- The use of the array of templates with different names is good to
provide different files accoring to a specific host (if there's the
relevant template, a more general zone (network or also department)
that you have to define with the custom variable $my_zone, or use a
fall back general use sshd_config.
- You may also decide to switch the logic that differentiates
configuration according to departments in the same template file.
For more info and examples about this approach you might find this
link useful: http://www.example42.com/wiki/InfrastructureDesignGuidelines
Regards,
Alessandro Franceschi
Rene wrote:
> Hi
>
> Our team is providing Linux servers to different departments in our
> company. We want to change our configuration management tool and use
> puppet in the future. I read the book “Pulling Strings with Puppet”
> and the documentation on the puppet webpage.
>
> When I understood correctly, the way to go is to use modules. So we
> would create modules for ssh, ldap, ntp etc… But the problem I have
> is, that different IT Departements use different configurations
> (different ssh config, different ntp conf etc…) So would I put the
> logic inside this modules or is it better to create different ssh
> modules for different departments? (I think the second one is not a
> good choice, since with that we have the same resources defined in the
> different modules and I think this is a problem, isn’t it?)
>
> Another question I have is about the services directory. Is my
> understanding right, that services is just a grouping of modules?
>
> Thanks in advance
>
> Rene
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] EAL4+ general hardening settings with Puppet
Hallo Puppet Masters, if you are interested in a puppet-based general hardening setup following the EAL4+ CAPP guidelines you may find useful what I've reported here: http://www.example42.com/wiki/EalHardening It has been tested on Centos 5 but should seamlessly apply to RHEL 5 and with minor corrections to RHEL4. Consider it a work in progress and by no means a complete solution to achieve a certified EAL4+ system (that involves further steps that range from installation of a systems to operations). These hardening settings are a subset of a more general Example(42) Puppet Infrastructure ( http://www.example42.com ) a set of modules (in alpha/beta stage) that can be be freely used as as starting point for a custom Puppet setup. Feedbacks, improvements and comments are welcomed. Best regards, Alessandro Franceschi Lab42 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
Hi Digant,
what's the best place to comment/discuss what is written in:
http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards ?
I'd like to take part in the discussion about the module standards but
I don't think the wiki is the right places to submit ideas/remarks.
So for the moment I write here.
For example I find point 5 in the Modules Standards section, a bit
over engineered and not well manageable in the log term:
I don't find the necessity to introduce a new variable for every
package and service name (and pathname for almost each file served, so
in some cases you should define a lot of variables for a module).
I would handle the operating systems differences where is necessary
with a relevant switch, like here:
class sendmail {
package {
sendmail:
name => $operatingsystem ? {
default => "sendmail",
},
ensure => present;
sendmail-cf:
name => $operatingsystem ? {
default => "sendmail-cf",
},
ensure => present,
}
service { sendmail:
name => $operatingsystem ? {
default => "sendmail",
},
ensure => running,
enable => true,
hasrestart => true,
hasstatus => true,
require => Package[sendmail],
}
file {
"sendmail.cf":
mode => 644, owner => root, group => root,
require => Package[sendmail],
ensure => present,
path => $operatingsystem ?{
default => "/etc/mail/sendmail.cf",
},
}
}
In any case, this is just an example (and, in this case, a solution or
another I guess it's mostly a matter of personal taste).
Another point quite critical, according to me, is the standardization
of modules that need to manage objects provided by other modules.
An example could be a module for a software like mailcanner or amavis
or whatever: they should handle configuration files and other objects
of different other programs (for example an MTA like postfix, mail
filters like spamassassin and clamav and so on).
How can this be handled in a modular standard way (the mantainer of
mailscanner module is not necessarily the postfix mantainer)?
I've thought about different scenarios but they all require some
tweaks that can be more or less acceptable (for example a conflict
with other modules).
Best regards,
al
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Setting up a syslog-ng server with puppet?
You may find useful this (for syslog-ng): http://live.lab42.it/puppetinfrastructure/browser/syslog-ng and this (for phpsyslogng web interface); http://live.lab42.it/puppetinfrastructure/browser/phpsyslogng Regards, al On Sep 22, 9:30 pm, "Brian Gupta" <[EMAIL PROTECTED]> wrote: > Anyone have any recipes for this? Also logrotate bits would help. > > -- > - Brian Gupta --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
