Re: [Puppet Users] Multiple Environments
2009/12/20 Russ Allbery : > The advantage of Git branches is that we can much more easily merge or > cherry-pick changes between the environments. For example, changes that > must be made in production can be made there and then merged into test, so > that test stays in sync easily but can maintain separate changes. > > Our intention is to then cut a new production branch from test every three > months and retain two production branches, cutting each production server > from the old branch over to the new branch on a quarterly cycle according > to the requirements of that production environment. That way, all servers > benefit from general architectural changes, but those changes are > thoroughly tested first in the test/dev environments (which will all point > to the master branch). +1 to Russ' approach. By maintaining branches and creating a lifecycle you can also fit the cycle to your change control, embed it in your ticketing system, etc, etc. Teaches good development lifecycle skills to admins too. :) 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) -- 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: Couldn't see RRDReport in foreman
Yes, I configured reporting in Foreman: puppet.conf report = log,store,tagmail,rrdgraph,foreman Copy file foreman-report.rb into dir /usr/lib/ruby/site_ruby/1.8/ puppet/reports/foreman.rb and as edited $foreman_url = "http://mypuppethost"; After this restart Apache - is the same result. RRDReports are not displayed in Foreman web page :( On 20 дек, 03:56, Ohad Levy wrote: > Did you enable reporting in Foreman? - > e.g.http://theforeman.org/wiki/foreman/Puppet_Reports > > I'm planning to generate all of the graphs within Foreman (no need to use > RRD anymore) soon (that is when I'll come back from Xmas vacation ), so > hopefully this wont be required and will look much nicer. > > Cheers, > Ohad > > On Sun, Dec 20, 2009 at 6:15 AM, koliama wrote: > > Hello, > > I have configured puppet 0.25.1+passenger+foreman 0.1-3+ruby-rrdtools > > (into fedora EPEL repository). > > When I try to look RRDRoport link by host I see "Close Sorry, no > > graphs for this host" > > When I try to look Reports link I couldn't see anything. But when I > > enter in adress bar "http:// mypuppethost/reports/host_fqdn/" - I see > > rrd reports graph (Daily, Weekly, e.t.c) > > How to configure puppet+foreman+apache for correct display puppet rrd > > reports in foreman web interface? > > > My conf: > > puppet.conf > > [main] > > external_nodes = /etc/puppet/node.rb > > node_terminus = exec > > vardir = /var/puppet > > logdir = $vardir/log > > rundir = $vardir/run > > ssldir = $vardir/ssl > > > [puppetmasterd] > > > reportdir = /var/puppet/reports > > reports = log,store,tagmail,rrdgraph > > tagmap = $confdir/tagmail.conf > > rrddir = $vardir/rrd > > rrdinternval = $runinterval > > rrdgraph = true > > ssl_client_header = SSL_CLIENT_S_DN > > ssl_client_verify_header = SSL_CLIENT_VERIFY > > autosign = /etc/puppet/autosign.conf > > modulepath = /etc/puppet/modules > > > apache.conf > > Listen 3000 > > > > ServerName puppet > > DocumentRoot /var/rails/foreman/public/ > > ErrorLog /var/rails/foreman/log/error_log > > LogLevel error > > > # Grant access to puppet reports > > Alias /reports/ /var/puppet/rrd/ > > > > PassengerEnabled off > > Options Indexes > > Order deny,allow > > Allow from all > > > > > > > foreman settingc.yaml > > --- > > :modulepath: /etc/puppet/modules/ > > :rrd_report_url: reports/ > > :puppet_server: srv2-puppet > > > -- > > > 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. > > -- 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.
Re: [Puppet Users] Multiple Environments
hello, - "Douglas Garstang" wrote: > I'd like to be able to split out my puppet production and test > environments so that I can continue to develop puppet > modules/manifests without breaking production. How are people doing > this? Puppet environments may be one way. I guess I'd have a > main(prod) environment and a test one. When I was finished with > testing, I could rsync the files over to the prod environment. Is > this > how others are doing it? http://www.devco.net/archives/2009/10/10/puppet_environments.php That's how I do it, aim is to avoid many copies of the same module just because we have multiple environments, but still have the ability to create those versions during the dev cycle. not for everyone, but maybe it help you in the right direction. -- 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.
Re: [Puppet Users] Re: Couldn't see RRDReport in foreman
reading your apache configs, i guess that foreman links to port 80 (and you are using 3000). you may switch to 80 or reformat the url statement yourself in app/views/hosts/_rrdreport.rhtml. cheers, Ohad On Sun, Dec 20, 2009 at 8:38 PM, koliama wrote: > Yes, I configured reporting in Foreman: > > puppet.conf > report = log,store,tagmail,rrdgraph,foreman > > Copy file foreman-report.rb into dir /usr/lib/ruby/site_ruby/1.8/ > puppet/reports/foreman.rb and as edited > $foreman_url = "http://mypuppethost"; > After this restart Apache - is the same result. RRDReports are not > displayed in Foreman web page :( > > On 20 дек, 03:56, Ohad Levy wrote: > > Did you enable reporting in Foreman? - e.g. > http://theforeman.org/wiki/foreman/Puppet_Reports > > > > I'm planning to generate all of the graphs within Foreman (no need to use > > RRD anymore) soon (that is when I'll come back from Xmas vacation ), so > > hopefully this wont be required and will look much nicer. > > > > Cheers, > > Ohad > > > > On Sun, Dec 20, 2009 at 6:15 AM, koliama wrote: > > > Hello, > > > I have configured puppet 0.25.1+passenger+foreman 0.1-3+ruby-rrdtools > > > (into fedora EPEL repository). > > > When I try to look RRDRoport link by host I see "Close Sorry, no > > > graphs for this host" > > > When I try to look Reports link I couldn't see anything. But when I > > > enter in adress bar "http:// mypuppethost/reports/host_fqdn/" - I see > > > rrd reports graph (Daily, Weekly, e.t.c) > > > How to configure puppet+foreman+apache for correct display puppet rrd > > > reports in foreman web interface? > > > > > My conf: > > > puppet.conf > > > [main] > > >external_nodes = /etc/puppet/node.rb > > >node_terminus = exec > > >vardir = /var/puppet > > >logdir = $vardir/log > > >rundir = $vardir/run > > >ssldir = $vardir/ssl > > > > > [puppetmasterd] > > > > >reportdir = /var/puppet/reports > > >reports = log,store,tagmail,rrdgraph > > >tagmap = $confdir/tagmail.conf > > >rrddir = $vardir/rrd > > >rrdinternval = $runinterval > > >rrdgraph = true > > >ssl_client_header = SSL_CLIENT_S_DN > > >ssl_client_verify_header = SSL_CLIENT_VERIFY > > >autosign = /etc/puppet/autosign.conf > > >modulepath = /etc/puppet/modules > > > > > apache.conf > > > Listen 3000 > > > > > >ServerName puppet > > >DocumentRoot /var/rails/foreman/public/ > > >ErrorLog /var/rails/foreman/log/error_log > > >LogLevel error > > > > > # Grant access to puppet reports > > > Alias /reports/ /var/puppet/rrd/ > > > > > >PassengerEnabled off > > >Options Indexes > > >Order deny,allow > > >Allow from all > > > > > > > > > > > foreman settingc.yaml > > > --- > > > :modulepath: /etc/puppet/modules/ > > > :rrd_report_url: reports/ > > > :puppet_server: srv2-puppet > > > > > -- > > > > > 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. > > > > > > -- > > 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. > > > -- 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.
Re: [Puppet Users] Multiple Environments
On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar wrote: > hello, > > - "Douglas Garstang" wrote: > >> I'd like to be able to split out my puppet production and test >> environments so that I can continue to develop puppet >> modules/manifests without breaking production. How are people doing >> this? Puppet environments may be one way. I guess I'd have a >> main(prod) environment and a test one. When I was finished with >> testing, I could rsync the files over to the prod environment. Is >> this >> how others are doing it? > > http://www.devco.net/archives/2009/10/10/puppet_environments.php > > That's how I do it, aim is to avoid many copies of the same module just > because we have multiple environments, but still have the ability to create > those versions during the dev cycle. > > not for everyone, but maybe it help you in the right direction. Thanks to everyone for the replies. Are you using multiple environments though? And, if using multiple environments, how do you structure it? The puppet documentation is a bit vague on the subject. For instance, it's not clear to me if you would structure it so that you have a top level dir ABOVE puppet called prod, test etc, or if you would create subdirs BELOW manifests, modules etc called prod, test. The next question is, where do you branch? If you have a top level dir above puppet, I guess that's pretty easy, but if you have multiple dirs below manifests, modules etc, then you'd need to branch each which becomes more complex. Doug -- 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.
Re: [Puppet Users] Managing the same file from multiple modules/classes/manifests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, I would place each relevant part into its own file and build the resulting file at the end of the manifest collection. This is an example of doing this: http://reductivelabs.com/trac/puppet/wiki/Recipes/BuildingMultipartFiles I seem to remember something more elegant out there but I can't seem to find it right now. I was hoping to create a custom type for this type of activity at some point that would build everything server side but haven't had the time. You can also use your PAM class to allow other classes to call out specific functionality such as unix-srr::pam::kerberos, where the called item is a specific define. Lastly, you can allow the setting of specific variables influence what you include in your PAM settings, but this is a bit error prone in execution from my experience. Trevor On 12/17/2009 08:21 PM, David Pheasant wrote: > Hey everyone, > > I accidentally sent an earlier (unfinished) version of this message to > the list, but hopefully it was moderated out. In any case, I'm > wondering about the best way to manage the contents of a single file > from multiple modules or maninfests/classes within the same module. > Specifically, I'm trying to manage the entries in /etc/pam.d/system- > auth-ac (we're running RedHat). > > Currently we have a module called 'unix-srr' that implements the DISA > unix security guidelines. One of the classes within this module (unix- > srr::pam) implements security settings that are involved with the > system-auth-ac file (password requirements, password history, su > usage). All the unix-srr::pam class does is define a file type that > updates/ensures the local file matches the version in the unix-srr/ > files/etc/pam.d/ module directory on the puppetmaster. > > Given the above scenario, what would be the best way to add the > ability to configure kerberos based authentication? This will also > require edits to the system-auth-ac file. I would like to put this > into a separate module/class since not all sites will need/require > kerberos authentication. As I see it there are two options: > > 1. Another class that re-implements the file based approach where the > source system-auth-ac file already includes the unix-srr changes. > > 2. Another class that implements an Augeas based solution. > > I think that we can all agree that Option 1 is a kludge since any > changes to the unix-srr version of the system-auth-ac file will also > have to be made to the kerberos-auth version; otherwise we'd have one > overwriting the other in an infinite loop. Option 2 is viable, but I > am annoyed by the amount of time that is required for changes via > Augeas since by default Augeas parses all files under /etc/. I have > tried setting the 'root' option of the augeas type to '/etc/pam.d/' > but this does not work as expected (I also tried this with augtool via > the AUGEAS_ROOT environment variable and it failed as well, so this is > an issue with Augeas and not puppet). > > So, does anyone have a suggestion for how to deal with this? I'm > pretty new to puppet so it may well be possible that the layout > described above is fundamentally flawed. > > Thanks in advance, > > -Dave > > -- > > 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. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksutUsACgkQyjMdFR1108BnhgCfePQnlpTIPFq++xz/k2Kfp0Dw VfMAnjIOYnBa1NBst/SXsmYHytbbpLT7 =ZT3+ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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.
Re: [Puppet Users] Modules metadata standards
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. Julian. -- 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.
Re: [Puppet Users] Multiple Environments
On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang wrote: > On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar wrote: >> hello, >> >> - "Douglas Garstang" wrote: >> >>> I'd like to be able to split out my puppet production and test >>> environments so that I can continue to develop puppet >>> modules/manifests without breaking production. How are people doing >>> this? Puppet environments may be one way. I guess I'd have a >>> main(prod) environment and a test one. When I was finished with >>> testing, I could rsync the files over to the prod environment. Is >>> this >>> how others are doing it? >> >> http://www.devco.net/archives/2009/10/10/puppet_environments.php >> >> That's how I do it, aim is to avoid many copies of the same module just >> because we have multiple environments, but still have the ability to create >> those versions during the dev cycle. >> >> not for everyone, but maybe it help you in the right direction. > > Thanks to everyone for the replies. > > Are you using multiple environments though? And, if using multiple > environments, how do you structure it? The puppet documentation is a > bit vague on the subject. For instance, it's not clear to me if you > would structure it so that you have a top level dir ABOVE puppet > called prod, test etc, or if you would create subdirs BELOW manifests, > modules etc called prod, test. > > The next question is, where do you branch? If you have a top level dir > above puppet, I guess that's pretty easy, but if you have multiple > dirs below manifests, modules etc, then you'd need to branch each > which becomes more complex. Hmmm. I'm not following this here. At the moment I have /etc/puppet, which is a working copy. Every now and then I commit my changes. I can add a dev environment to this working copy and safely use that to test modules and manifests on dev nodes, but there's still no way for me to roll those changes back to the production environment without some manual process. I could make a branch of /etc/puppet, and check it out, but then I'd need a second copy of puppetmaster running in a second location to test it against. I'm using passenger, so maybe I could fire up a second instance on another port, and maybe that would work. If I was to branch the prod dir inside puppet into a dev dir, then this is kind of where I get lost. If I was to branch /etc/puppet/dev or simialar, once again I'd need to check it out into a new location where I could work on it, and test it. This still needs a second copy of puppetmaster running, and it's actually worse this way because I don't have all the necessary puppet config from further up the tree. G. -- 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.
Re: [Puppet Users] Modules metadata standards
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/adc211ad191568e84eb3e1f618f1cbf78df95ba9 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) -- 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.
Re: [Puppet Users] Modules metadata standards
On Dec 20, 2009, at 4:09 PM, Julian Simpson wrote: > 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. > > Julian. > This is a topic that is sure to come up in more detail soon, as I'm ramping up work on the [yet to be named] "module forge" and related client tools. I'd love to see some examples of what the community thinks should be present in the metadata -- especially information beyond the authorship and dependency information. Perhaps a wiki page is a good place to start (focusing on the information to be supported -- not the format, which is an implementation detail). Cheers, Bruce -- Bruce Williams http://reductivelabs.com -- 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.
