Re: [Puppet Users] Re: A Question about mixing Puppet with other things
On Tue, Jul 12, 2011 at 6:26 PM, Dan White y...@comcast.net wrote: This tells me RedHat picked Foreman over Cobbler. It does not tell me WHY. Their reasons may not apply to my situation. I am not trying to be difficult, but I find that I cannot accept an opinion on a technical issue without technical information to back it up. Also, this is for my job, so I need to be able to justify my decision with more than The folks on the puppet mailing list told me to do it this way. I think I can try to break it down in different ways. First, Foreman was created after realizing that Just pxe booting, or just using puppet, does not cover everything. With the notion of self service (e.g. people who don't know how to use puppet and or lack access to your manifests) foreman was aiming to bridge that gap. Therefore, it was designed as a web service from day one, taking into account multiple users, permissions, different views etc etc. Another goal, was that you wont need to open 5 different consoles in order to provision a host, that eventually lead to integrating: dns, dhcp, tftp, puppetca, virtual machine creation, puppet class assignments, hierarchical variables support, audit log etc all in one place. Foreman users have come up with interesting usages cases, from using it purely for monitoring puppet to ramp up whole datacenters. its API is used today to feed external monitoring services, provision hosts, update on the fly many hosts, and there is even a mobile app who utilize foreman. Foreman is also not restricted to a specific subnet, datacenter etc, rather is supposed to work across network segments and different backend software (e.g. ms dns server, isc dhcp server etc) using its smart proxy architecture. My hope, is that by using Foreman, you can provide your users much better service, taking you out of the deployment loop, e.g. You users can consume your services, without you being actively part of it. I obviously didnt cover every single aspect of foreman, but I hope it gives you some useful information, if not, simply ask, or join our mailing list or irc room (#theforeman) to ask more questions. Ohad “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Brian b...@uga.edu wrote: On Jul 7, 2:47 pm, Dan White y...@comcast.net wrote: In Pro Linux System Administration Mr. Turnbull discusses Cobbler and Puppet In Pro Puppet he discusses Foreman and Puppet. Would anyone out there be willing and able to talk about the differences between Cobbler and Foreman as they relate to Puppet and what factors I should consider in choosing one of them ? Red Hat is using Foreman in CloudForms System Engine, their successor to Satellite. I'd take this as a strong vote of confidence in Foreman. https://www.redhat.com/archives/spacewalk-list/2011-July/msg00019.html All the best, Brian -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- 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: how to write classes to install package from source
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 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 Question about mixing Puppet with other things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 05:26 PM, Dan White wrote: This tells me RedHat picked Foreman over Cobbler. It does not tell me WHY. Their reasons may not apply to my situation. I am not trying to be difficult, but I find that I cannot accept an opinion on a technical issue without technical information to back it up. Also, this is for my job, so I need to be able to justify my decision with more than The folks on the puppet mailing list told me to do it this way. * strong: foreman, thanks to its smart proxies, is not that subnet oriented as cobbler is. Means: You can use one foreman to deploy things into multiple subnets/locations from one installation, which gets much more complicated with cobbler. * strong: foreman integrates puppet from the beginning on, means for example: ** strong: foreman integrates the configuration of puppet nodes, while cobbler has a much simpler general external parameter option meant for any configuration management system ** strong: foreman integrates puppet reporting, while with cobbler you would need another tool, like dashboard. * strong: foreman has much better support for other distros than redhat based distros * medium: cobbler has better integration to address baremetals, like powering them on via powerbars. According to my current knowledge foreman doesn't (yet) have the capability to tell powerbars to turn baremetals on. * medium non-technical: cobbler is integrated in the current spacewalk/satellite solution, while foreman is part of the next generation of redhat's satellite. - http://katello.org * medium: cobbler can also manage external repositories, while foreman rather delegates that to other tools (rsync scripts,...). * uncertain, but rather strong: foreman has better integration with libvirt, actually within the webinterface cobbler doesn't have one at all imho. but I could be wrong... * weak: foreman is written in the same language as puppet, so if you anyway would have to learn both ruby and python, it might be easier to have 2 new tools written in the same language ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dNUsACgkQbwltcAfKi3/fFgCfUvOZ2gP0TzDIiy6gg21IQbCy 41wAnA/J49OLHpaILc+yBIabjbZ8Kphd =P2nf -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Seemingly random failures after 2.7.1 upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is using an empty class in init.pp problematic ? All of these modules
worked just fine before going from 2.6.8 to 2.7.1.
I have no idea, whether this is the problem. But why do you do:
# manifests/init.pp
import classes/*.pp
class kvm {
}
# manifests/classes/host.pp
class kvm::host {
?
Why not just have one file manifests/host.pp that contains the kvm::host
class? Everything else is not really necessary.
Puppet has quite a powerfull autoloading feature of classes and I think
it can be seen as a general best practice to have one class in a file in
its corresponding path on the filesystem.
With your current way you would need a global import kvm, so that the
init.pp class is actually parsed, so that the files in classes/ are
imported.
If this is not the case and the kvm::host class is not in a file that
can be found by the autoloader it won't find the class.
This becomes even trickier as other hosts can now interfere which
classes are available while compiling the next hosts classes, as an
import statement might only have been executed if Host A is compiled and
only this would then make these imported classes that Host B requires
available.
Actually, I remember that the autoloader should also look into init.pp
for the kvm::host class. But it's possible that something like that
might have changed in 2.7. But I don't know it.
Due to these two reasones (magic availability of classes, possible
changes in how classes become available in 2.7) I would generally
recommend to *not* use import statements and instead use puppet's
autoloading feature. They're rather hard to debug.
~pete
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4dOygACgkQbwltcAfKi39akACcCwslVzxzrTy3/H0r7kGyi4dB
M4gAn1LHtc/LGk7OtbVfDolhm5cXwm/p
=lWHm
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: how to write classes to install package from source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 12:19 PM, Al @ Lab42 wrote: You might find this define useful ( https://github.com/example42/puppet-modules/blob/master/common/manifests/defines/netinstall.pp ): or as a general best practice you might want to build your own packages. They're much easier to handle! ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dO2kACgkQbwltcAfKi3+5WQCfa35P0lZKGS8xYyitmfLt7Kiy wUwAn0pnp4xscGeMNl3VA1Lo1xSygYh9 =ZGSf -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Best way to create a repo, looking for advice and tips
Hi, Not sure I completely understand what you're after but i'll try to give an answer (from a red hat perspective). Yes you can set up a repo that you point puppet clients at. yumrepo allows you to describe that. Yes you can use the yum tool createrepo to create a yum repo from a bunch of rpms. It is a sound idea to create your own repo for packages when you have change control obligations or security concerns about package management. It's also really useful when you compile your own packages. So from that it is pretty easy to achieve. What does get fiddly is dependency management but if things don't change often it might be worth the effort. If you use EC2 or virtualbox it is neither here nor there really. Cheers Den On 13/07/2011, at 15:19, S Ahmed sahmed1...@gmail.com wrote: What is the best way to create a repo? I like to take baby steps, and test things as I go. Is this kind of development style possible with puppet? My hope was to do something like: Have 1 ec2 vm open that will be my test vm where I will manually install e.g. mysql or nginx, and then look at what files I will need to work with. Make modifications to my puppet repo, then commit and apply the changes on a single VM that will I will just manually apply the repo to. (I believe this is possible i.e. to apply a repo on a system that isn't running a puppet master, please correct me if I am wrong, I swear I read it somewhere). Once I have things all setup, I will then test things with a real puppet master and node(s). Is this a good approach? Comments? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Testing if a puppet class is going to be installed
On Thu, 07 Jul 2011, Keith Minkler wrote: For example, for setting up the proper nagios monitors, you'd want to say something like if this machine has the apache class, then configure apache monitoring It's not feasible I think to put this logic in the apache class, since you'd have to have a way to build up the nagios config file from parts contained in many classes which sometimes are installed together. I would probably use a concatenated file for this. Define a function in the nagios class that means please monitor this service using these parameters, and let the apache class call that. Behind the scenes, the nagios class would use concat and concat::fragment to do the work. See http://www.devco.net/archives/2010/02/19/building_files_from_fragments_with_puppet.php for an example. --apb (Alan Barrett) -- 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: How to avoid the use of defined
Hi,
First, thanks for your help. However I still have some issues with your
solution.
jcbollinger john.bollin...@stjude.org writes:
few bad ones. Here's a good rule of thumb: never use Puppet's
defined() function in your manifests. Ever. It is brittle, and it
will cause you grief, increasing exponentially with the number of
uses.
.../...
There is no need for subclassing or defined() here. I would approach
the problem something like this:
# Resource defaults for Packages in this class
Package {
ensure = installed,
require = Package['php'],
notify = Service['httpd']
}
This creates a dependency loop:
err: Could not apply complete catalog: Found dependency cycles in the following
relationships: Package[php] = Package[httpd], Package[httpd] = Package[php],
Package[php] = Package[php-ldap], Package[php-imap] = Package[php-mysql],
Package[php-gd] = Package[php-mysql], Package[php-ldap] = Package[php-mysql],
Package[php] = Package[php-mysql], Package[httpd] =
File[/etc/httpd/conf.d/mod-status.conf], Package[php] = Package[php-mbstring],
Package[httpd] = Service[httpd], Package[httpd] = Service[httpd],
Package[php-imap] = Service[httpd], Package[php-mysql] = Service[httpd],
Package[php-gd] = Service[httpd], Package[php-ldap] = Service[httpd],
Package[php] = Service[httpd], File[/etc/httpd/conf.d/mod-status.conf] =
Service[httpd], Package[php-mbstring] = Service[httpd], Package[php] =
Package[php-imap], Package[php] = Package[php-gd], Package[httpd] =
File[/var/www/html]; try using the '--graph' option and open the '.dot' files
in OmniGraffle or GraphViz
As far as I understand, Package['httpd'] (defined in class apache::base)
inherits the dependency on Package['php']. This is using Puppet 2.6.8;
has this changed in 2.7.x?
# ** No class apache::php53 **
So how do I tell Puppet which nodes need 5.1 and which need 5.3? With my
sample wordpress class I get the following error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could
not find class apache::php53 in namespaces wordpress at
/etc/puppet/modules/wordpress/manifests/init.pp:6 on node testxen1.ircam.fr
Looks like using a dummy class definition as a flag won't work. :-) I
could use a variable instead, but I guess the ordering issues would get
even worse?
# class apache::params unchanged, not shown
So I'm still using defined().
As my manifest shows, I'm not sure yum replace is really needed. If
it is needed after all, then it shouldn't be too hard to adjust the
above to use it.
Actually your solution looks much cleaner than yum replace.
--
Arnaud
--
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] puppet manifest execution orders
I created manifest for our webserver. manifest included git clone, database creation and restore database etc How to order the installation and exec exactly Roni -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet manifest execution orders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2011 08:51 AM, Roni wrote: I created manifest for our webserver. manifest included git clone, database creation and restore database etc How to order the installation and exec exactly by using require, before, notify, subscribe... ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dey4ACgkQbwltcAfKi39V5ACgmVJlYay6nCMQ/NruO/yiICHf XysAoJ89DzSQ74/rTyxmTTIGLUcvI5Ai =wY2a -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: A Question about mixing Puppet with other things
Thank you, Ohad. This is the sort of info I am looking for. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Ohad Levy ohadl...@gmail.com wrote: On Tue, Jul 12, 2011 at 6:26 PM, Dan White y...@comcast.net wrote: This tells me RedHat picked Foreman over Cobbler. It does not tell me WHY. Their reasons may not apply to my situation. I am not trying to be difficult, but I find that I cannot accept an opinion on a technical issue without technical information to back it up. Also, this is for my job, so I need to be able to justify my decision with more than The folks on the puppet mailing list told me to do it this way. I think I can try to break it down in different ways. First, Foreman was created after realizing that Just pxe booting, or just using puppet, does not cover everything. With the notion of self service (e.g. people who don't know how to use puppet and or lack access to your manifests) foreman was aiming to bridge that gap. Therefore, it was designed as a web service from day one, taking into account multiple users, permissions, different views etc etc. Another goal, was that you wont need to open 5 different consoles in order to provision a host, that eventually lead to integrating: dns, dhcp, tftp, puppetca, virtual machine creation, puppet class assignments, hierarchical variables support, audit log etc all in one place. Foreman users have come up with interesting usages cases, from using it purely for monitoring puppet to ramp up whole datacenters. its API is used today to feed external monitoring services, provision hosts, update on the fly many hosts, and there is even a mobile app who utilize foreman. Foreman is also not restricted to a specific subnet, datacenter etc, rather is supposed to work across network segments and different backend software (e.g. ms dns server, isc dhcp server etc) using its smart proxy architecture. My hope, is that by using Foreman, you can provide your users much better service, taking you out of the deployment loop, e.g. You users can consume your services, without you being actively part of it. I obviously didnt cover every single aspect of foreman, but I hope it gives you some useful information, if not, simply ask, or join our mailing list or irc room (#theforeman) to ask more questions. Ohad “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Brian b...@uga.edu wrote: On Jul 7, 2:47 pm, Dan White y...@comcast.net wrote: In Pro Linux System Administration Mr. Turnbull discusses Cobbler and Puppet In Pro Puppet he discusses Foreman and Puppet. Would anyone out there be willing and able to talk about the differences between Cobbler and Foreman as they relate to Puppet and what factors I should consider in choosing one of them ? Red Hat is using Foreman in CloudForms System Engine, their successor to Satellite. I'd take this as a strong vote of confidence in Foreman. https://www.redhat.com/archives/spacewalk-list/2011-July/msg00019.html All the best, Brian -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: A Question about mixing Puppet with other things
Thank you, Peter. This is the type of response I wanted. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Peter Meier peter.me...@immerda.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 05:26 PM, Dan White wrote: This tells me RedHat picked Foreman over Cobbler. It does not tell me WHY. Their reasons may not apply to my situation. I am not trying to be difficult, but I find that I cannot accept an opinion on a technical issue without technical information to back it up. Also, this is for my job, so I need to be able to justify my decision with more than The folks on the puppet mailing list told me to do it this way. * strong: foreman, thanks to its smart proxies, is not that subnet oriented as cobbler is. Means: You can use one foreman to deploy things into multiple subnets/locations from one installation, which gets much more complicated with cobbler. * strong: foreman integrates puppet from the beginning on, means for example: ** strong: foreman integrates the configuration of puppet nodes, while cobbler has a much simpler general external parameter option meant for any configuration management system ** strong: foreman integrates puppet reporting, while with cobbler you would need another tool, like dashboard. * strong: foreman has much better support for other distros than redhat based distros * medium: cobbler has better integration to address baremetals, like powering them on via powerbars. According to my current knowledge foreman doesn't (yet) have the capability to tell powerbars to turn baremetals on. * medium non-technical: cobbler is integrated in the current spacewalk/satellite solution, while foreman is part of the next generation of redhat's satellite. - http://katello.org * medium: cobbler can also manage external repositories, while foreman rather delegates that to other tools (rsync scripts,...). * uncertain, but rather strong: foreman has better integration with libvirt, actually within the webinterface cobbler doesn't have one at all imho. but I could be wrong... * weak: foreman is written in the same language as puppet, so if you anyway would have to learn both ruby and python, it might be easier to have 2 new tools written in the same language ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dNUsACgkQbwltcAfKi3/fFgCfUvOZ2gP0TzDIiy6gg21IQbCy 41wAnA/J49OLHpaILc+yBIabjbZ8Kphd =P2nf -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet manifest execution orders
On Tue, Jul 12, 2011 at 11:51 PM, Roni roni...@gmail.com wrote: I created manifest for our webserver. manifest included git clone, database creation and restore database etc How to order the installation and exec exactly Roni, you really should have a run through our Learning Puppet series. http://docs.puppetlabs.com/learning/ordering.html -- Nigel Kersten Product Manager, Puppet Labs Twitter: @nigelkersten *Join us for **PuppetConf *http://www.bit.ly/puppetconfsig September 22nd and 23rd in Portland, Oregon, USA. * * -- 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] Seemingly random failures after 2.7.1 upgrade
On Tue, Jul 12, 2011 at 11:29 PM, Peter Meier peter.me...@immerda.chwrote: Puppet has quite a powerfull autoloading feature of classes and I think it can be seen as a general best practice to have one class in a file in its corresponding path on the filesystem. What he said. :) Life really does become a lot simpler if you avoid 'import' everywhere you can and just rely upon the class autoloader. -- Nigel Kersten Product Manager, Puppet Labs Twitter: @nigelkersten *Join us for **PuppetConf *http://www.bit.ly/puppetconfsig September 22nd and 23rd in Portland, Oregon, USA. * * -- 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: How to avoid the use of defined
On Jul 13, 5:34 am, Arnaud Gomes-do-Vale arnaud.go...@ircam.fr
wrote:
Hi,
First, thanks for your help. However I still have some issues with your
solution.
jcbollinger john.bollin...@stjude.org writes:
few bad ones. Here's a good rule of thumb: never use Puppet's
defined() function in your manifests. Ever. It is brittle, and it
will cause you grief, increasing exponentially with the number of
uses.
.../...
There is no need for subclassing or defined() here. I would approach
the problem something like this:
# Resource defaults for Packages in this class
Package {
ensure = installed,
require = Package['php'],
notify = Service['httpd']
}
This creates a dependency loop:
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: Package[php] = Package[httpd], Package[httpd] =
Package[php], Package[php] = Package[php-ldap], Package[php-imap] =
Package[php-mysql], Package[php-gd] = Package[php-mysql], Package[php-ldap]
= Package[php-mysql], Package[php] = Package[php-mysql], Package[httpd] =
File[/etc/httpd/conf.d/mod-status.conf], Package[php] =
Package[php-mbstring], Package[httpd] = Service[httpd], Package[httpd] =
Service[httpd], Package[php-imap] = Service[httpd], Package[php-mysql] =
Service[httpd], Package[php-gd] = Service[httpd], Package[php-ldap] =
Service[httpd], Package[php] = Service[httpd],
File[/etc/httpd/conf.d/mod-status.conf] = Service[httpd],
Package[php-mbstring] = Service[httpd], Package[php] = Package[php-imap],
Package[php] = Package[php-gd], Package[httpd] = File[/var/www/html]; try
using the '--graph' option and open the '.dot' files in OmniGraffle or
GraphViz
As far as I understand, Package['httpd'] (defined in class apache::base)
inherits the dependency on Package['php']. This is using Puppet 2.6.8;
has this changed in 2.7.x?
Fair enough, then move the 'require' parameter back out of resource
defaults into individual Package resources. Using resource defaults
is not an essential aspect of the solution.
# ** No class apache::php53 **
So how do I tell Puppet which nodes need 5.1 and which need 5.3? With my
sample wordpress class I get the following error:
See below.
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find class apache::php53 in namespaces wordpress at
/etc/puppet/modules/wordpress/manifests/init.pp:6 on node testxen1.ircam.fr
Looks like using a dummy class definition as a flag won't work. :-) I
could use a variable instead, but I guess the ordering issues would get
even worse?
As I wrote, Everybody that needs PHP just includes apache::php.
There is no more apache::php53.
# class apache::params unchanged, not shown
So I'm still using defined().
Ah. That's a blunder on my part. These are the alternatives I can
think of:
1) Per node, set a global variable that directs which set of PHP
packages to use.
2) Use extlookup() to retrieve a flag variable such as described in
(1), or else to retrieve the individual PHP package names.
3) Base the PHP package selection on node facts (possibly just
$hostname) instead of on defined()
4) Though I don't favor parameterized classes, you could parameterize
apache::php to allow your nodes to direct which set of PHP packages to
use; whether this is feasible depends somewhat on how the class is
used.
Another way to do this might be to stick with apache::php53 as a
subclass of apache::php, and use resource overrides. This is clean
only if you don't need the PHP package names in other classes, but it
looks like you're relying on titles instead of names anyway. The
result might be something like this:
class apache::php {
include 'apache::base'
package { 'php':
ensure = installed,
require = Package['httpd'],
notify = Service['httpd'];
'php-gd':
ensure = installed,
require = Package['php'],
notify = Service['httpd'];
'php-imap':
ensure = installed,
require = Package['php'],
notify = Service['httpd'];
'php-ldap':
ensure = installed,
require = Package['php'],
notify = Service['httpd'];
}
}
class apache::php53 inherits apache::php {
# $os is defined in site.pp.
if $::os == 'rhel5' {
Package['php'] { name = 'php53u' }
Package['php-gd'] { name = 'php53u-gd' }
Package['php-imap'] { name = 'php53u-imap' }
Package['php-ldap'] { name = 'php53u-ldap' }
package { 'php-alt':
name = 'php',
ensure = absent,
require = undef,
before = Package['php']
}
}
else {
warning 'Class apache::php53 should only ever be defined for RHEL5
and its clones.'
}
}
#
# No class apache::params, at least as pertains to apache::php
#
RHEL5 nodes that want PHP 5.3 then include apache::php53. It is safe,
but unnecessary, for such nodes also to include apache::php.
--
John
--
You received this message because you are subscribed to the Google
Re: [Puppet Users] Re: How to avoid the use of defined
On Wed, Jul 13, 2011 at 3:34 AM, Arnaud Gomes-do-Vale arnaud.go...@ircam.fr
wrote:
# Resource defaults for Packages in this class
Package {
ensure = installed,
require = Package['php'],
notify = Service['httpd']
}
This creates a dependency loop:
An option here is to override the require on a per-package basis.
If you set a resource default for require, and then separately set require
for individual resources, they will overwrite the resource default rather
than append to it.
You could also use collections to do what you want, this is untested, but
something like:
Package | title != php | {
require = Package['php'],
notify = Service['httpd']
}
should work I believe.
--
Nigel Kersten
Product Manager, Puppet Labs
Twitter: @nigelkersten
*Join us for **PuppetConf *http://www.bit.ly/puppetconfsig
September 22nd and 23rd in Portland, Oregon, USA.
*
*
--
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 never finishing when there are thousands of resources
On Jul 12, 9:53 pm, Rich Rauenzahn rraue...@gmail.com wrote: We are using puppet to export nagios resources (now we're using file resources to represent them) and the number of resources is probably in the thousands -- our puppet runs take 6GB (on the client side) and then just sort of spin forever (it's been running for a couple of hours now -- and no, we're not paging.) We're using puppet 2.6.4 and ruby 1.8.6 -- upgrading is on our roadmap, but we need to fight a few other fires first. Anyone have any suggestions for fixing this? Or how to mitigate this? I wonder if something isn't scaling -- like maybe the number of edges in the puppet DAG is increasing exponentially I don't know whether the size of the DAG is actually your problem, but it sounds like it might be. On that topic, then ... Relationships involving whole classes, especially of one whole class on another, tend to add a lot of edges that are not strictly necessary, because they are reduced to multiple inter-resource dependencies. That is, given Class['a'] - Class['b'], you get a relationship between each of the n resources of Class['a'] and each of the m resources of Class['b'], for n x m DAG edges. Run stages magnify that effect, because they establish relationships between each class in a given stage and each class in each later stage. If there is a total of r resources under management, then the number of DAG edges can scale as poorly as O(r*r). It would be a rare manifest set indeed where all those relationships are actually needed. If you must use run stages (not a given!) then keeping as many classes as possible in the main stage will tend to improve DAG scaling. The scaling effect for individual class relationships can be somewhat managed by careful factoring of your classes into those intended for other modules to depend on (these contain only a few key resources) and those intended for use only inside the same module, coupled with using only resource-level relationships intra-module. For the most precise control and minimum number of DAG edges, however, use only resource-level relationships everywhere, and audit those relationships ruthlessly. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet never finishing when there are thousands of resources
On Wed, Jul 13, 2011 at 8:27 AM, jcbollinger john.bollin...@stjude.orgwrote: Relationships involving whole classes, especially of one whole class on another, tend to add a lot of edges that are not strictly necessary, because they are reduced to multiple inter-resource dependencies. That is, given Class['a'] - Class['b'], you get a relationship between each of the n resources of Class['a'] and each of the m resources of Class['b'], for n x m DAG edges. Note that 2.7.x resolved this relationship explosion, which is one reason I suggested trying that. -- Nigel Kersten Product Manager, Puppet Labs Twitter: @nigelkersten *Join us for **PuppetConf *http://www.bit.ly/puppetconfsig September 22nd and 23rd in Portland, Oregon, USA. * * -- 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] Moving config to an ENC
Thanks for the response Dan, that was an easy fix.
Here is a trace:
# puppet agent -t --trace
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:56:in `deserialize'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:75:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:188:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:240:in
`retrieve_new_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:429:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:428:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:239:in
`retrieve_new_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:86:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:111:in
`retrieve_and_apply_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:150:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:172:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:172:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:305:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:420:in `hook'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:305:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:411:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:305:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:62:in `execute'
/usr/bin/puppet:4
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Invalid parameter yumreposerver::locations on node
kinks.corp.localmatters.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
On Tue, Jul 12, 2011 at 11:35 PM, Dan Bode d...@puppetlabs.com wrote:
On Tue, Jul 12, 2011 at 10:43 AM, Justin Lambert
jlamb...@localmatters.com wrote:
I have just gotten to playing with this and am doing something wrong,
probably very basic.
On the puppetmaster (which for my testing is also the client) I have
create_resources.rb in /var/lib/puppet/lib/puppet/parser/functions.
I wrote a new ENC that will just output a very basic YAML to test this,
the output is:
classes:
yumreposerver:
yumreposerver::locations:
centos5:
distro: centos
version: 5.6
it should be something like:
yumreposerver:
instances:
centos5:
distro:
...
there is no yumreposerver parameter in the yum server class, only an
instances parameter
In my modules directory I have yumreposerver/manifests/locations.pp:
class yumreposerver::locations ( $instances = {} )
{
create_resources('yumreposerver::location', $instances)
}
yumreposerver/manifests/location.pp:
define yumreposerver::location( $distro, $version ) {
.
}
puppet agent -t --noop returns:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Invalid parameter yumreposerver::locations on node name
I agree that this is not a very clear error message, can you run with
--trace?
Puppet version 2.6.9 on SL6.
Any insight as to where I have gone wrong?
Thanks,
jl
On Wed, Jul 6, 2011 at 7:22 AM, Justin Lambert jlamb...@localmatters.com
wrote:
This looks exactly like what I was looking for, thank you. This might be
worth mentioning on the ENC page so people like myself can find it easier.
On Tue, Jul 5, 2011 at 10:42 PM, Dan Bode d...@puppetlabs.com wrote:
Hi J,
The create resources function was created to serve this exact use case
(the README actually mentions your exact use case :) )
https://github.com/puppetlabs/puppetlabs-create_resources
This will require 2.6.5 or higher to work (That is the first version
where ENC's support param classes)
The function was also merged into core in 2.7.0
-Dan
On Tue, Jul 5, 2011 at 1:40 PM, Justin Lambert
jlamb...@localmatters.com wrote:
I have recently started moving the config of our puppet hosts out of
the nodes files and into an ENC so they can be managed through a web UI by
someone with less technical experience without the fear of a typo causing
a
failure of all catalogs to compile. As a result, I have been looking at
which modules need to be rewritten to support this. The problem I have
run
into is, how do you do something such as add multiple virtual hosts using
the YAML output of an ENC?
I currently have
[Puppet Users] Exported Resources with --noop
When I puppet with the noop flag resources are being exported to the db. Is this expected or a bug? I would expect it to simulate the transaction with the db... -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-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: What is the best practice to clean up installed components on a node?
I've always thought there should be an implicit X::disabled class that gets included for every host where X isn't included. Then if I create said class, it gets automatically executed on all hosts that don't include X. As it is now, one still has to go through and add X::disabled to every host, which is largely defeating the purpose of having a X::disabled class in the first place. (That purpose, for those not paying attention, is to make sure that things are in a known state, including services *not* running where they shouldn't be.) d. Create a class called sg_node::disabled that inherits sg_node and overrides all of it's resources to undo them. This usually means setting 'ensure =absent' (or 'undef' if applicable) for most resources. For execs, I usually set 'unless = true.' -- 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] wrong nodes.pp being accessed by the client
I have two development environments, main and development and my puppet.conf looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter pluginsync=false templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [development] modulepath = /etc/puppet/environments/development/modules manifests=/etc/puppet/environments/development/manifests/site.pp I have made nodes.pp for both environments. now when I execute the following on the client: puppetd --test --verbose --environment development it access the nodes.pp in the /etc/puppet/manifests rather than going to /etc/puppet/environments/development/manifests/nodes.pp In my site.pp stored at /etc/puppet/environments/development/manifests/ site.pp I have the following: import 'nodes.pp' How should I make puppet access the correct nodes.pp??? -- 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] help with new type
I'm trying to create a new type.. I followed the example on the wiki
and I have for the the type
module Puppet
newtype(:append_if_no_such_line) do
@doc = Ensure that the given line is defined in the file, and append
the line to the end of the file if the line isn't already in
the file.
newparam(:name) do
desc The name of the resource
isnamevar
end
newparam(:file) do
desc The file to examine (and possibly modify) for the line.
end
newparam(:user) do
desc The user
end
newparam(:line) do
desc The line we're interested in.
end
newproperty(:ensure) do
desc Whether the resource is in sync or not.
defaultto :insync
def retrieve
File.readlines(resource[:file]).map { |l|
l.chomp
}.include?(resource[:line]) ? :insync : :outofsync
end
newvalue :outofsync
newvalue :insync do
File.open(resource[:file], 'a') { |fd| fd.puts resource[:line] }
end
end
end
end
My manifest is this
append_if_no_such_line { foobar:
file = /tmp/foobar.txt,
line = some line of text,
user = test,
ensure = insync,
}
The error is
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter user at
/etc/puppet/manifests/modules/brsoft/manifests/history.pp:11 on node
history-v01-00a.domain.com
If i remove the user part from the manifest, it works just fine.. i'm
scratching my head a bit
thanks
mike
--
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: wrong nodes.pp being accessed by the client
I got the solution as I realize that puppet server needs to have only one nodes.pp for every environment and as client with different environments connect puppet looks for their module paths and install the respective packages, all the node entries irrespective of the environment they are attached to goes in the /etc/puppet/manifests/ nodes.pp. Please correct me if I am wrong. On Jul 13, 11:18 am, newguy aimanparv...@gmail.com wrote: I have two development environments, main and development and my puppet.conf looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter pluginsync=false templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [development] modulepath = /etc/puppet/environments/development/modules manifests=/etc/puppet/environments/development/manifests/site.pp I have made nodes.pp for both environments. now when I execute the following on the client: puppetd --test --verbose --environment development it access the nodes.pp in the /etc/puppet/manifests rather than going to /etc/puppet/environments/development/manifests/nodes.pp In my site.pp stored at /etc/puppet/environments/development/manifests/ site.pp I have the following: import 'nodes.pp' How should I make puppet access the correct nodes.pp??? -- 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: wrong nodes.pp being accessed by the client
No, you're right, at least as far as I've been able to tell – though I certainly may have overlooked something. The puppetmaster only gets the configs from one environment, so you're stuck using that. There are other consequences as well, such as defined resources using the definition in the server's environment. Some of this is design, and some is from bugs: http://projects.puppetlabs.com/issues/4409 It is, to my mind, a pretty serious deficiency – one makes safely testing significant changes much harder. It's enough of a pain that I've considered running a separate puppet master just for serving the testing environment. d. On Jul 13, 2011, at 11:43, newguy wrote: I got the solution as I realize that puppet server needs to have only one nodes.pp for every environment and as client with different environments connect puppet looks for their module paths and install the respective packages, all the node entries irrespective of the environment they are attached to goes in the /etc/puppet/manifests/ nodes.pp. Please correct me if I am wrong. On Jul 13, 11:18 am, newguy aimanparv...@gmail.com wrote: I have two development environments, main and development and my puppet.conf looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter pluginsync=false templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [development] modulepath = /etc/puppet/environments/development/modules manifests=/etc/puppet/environments/development/manifests/site.pp I have made nodes.pp for both environments. now when I execute the following on the client: puppetd --test --verbose --environment development it access the nodes.pp in the /etc/puppet/manifests rather than going to /etc/puppet/environments/development/manifests/nodes.pp In my site.pp stored at /etc/puppet/environments/development/manifests/ site.pp I have the following: import 'nodes.pp' How should I make puppet access the correct nodes.pp??? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Seemingly random failures after 2.7.1 upgrade
Hi! I've also noticed this (weird) behaviour. I am planning an (huge) upgrade (from 0.25.x to 2.7.1) in all my puppet's boxes... I've installed puppet's 2.7.1 gem and got a lot of Could not find class problem... and everything worked just fine with 0.25.x. So, I decided to uninstall the gem for version 2.7.1 and install puppet version 2.6.9. Everything worked just fine... no weird Could not find class problem... am I missing something? Thanks in advance, Gus On Jul 13, 11:03 am, Nigel Kersten ni...@puppetlabs.com wrote: On Tue, Jul 12, 2011 at 11:29 PM, Peter Meier peter.me...@immerda.chwrote: Puppet has quite a powerfull autoloading feature of classes and I think it can be seen as a general best practice to have one class in a file in its corresponding path on the filesystem. What he said. :) Life really does become a lot simpler if you avoid 'import' everywhere you can and just rely upon the class autoloader. -- Nigel Kersten Product Manager, Puppet Labs Twitter: @nigelkersten *Join us for **PuppetConf *http://www.bit.ly/puppetconfsig September 22nd and 23rd in Portland, Oregon, USA. * * -- 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] Solaris mount provider question
I'm trying to mount multiple swap partitions in Solaris, but I'm not sure
how to create a working syntax for that. Since the mountpoint for a swap
partition is '-' adding more than one is going to result in a multiple
declaration.
I'd like to do something like this:
mount { '-':
device = '/dev/zvol/dsk/rpool/swap01',
fstype = swap,
atboot = no,
options = -,
}
mount { '-':
device = '/dev/zvol/dsk/upool/swap02',
fstype = swap,
atboot = no,
options = -,
}
I would use the 'path' property, but it's listed as deprecated and I'd
rather not have my manifest break upon upgrading. Is there a better way to
do this that I'm missing?
--
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] Exported Resources with --noop
On 11-07-13 12:06 PM, Andrew Thompson wrote: When I puppet with the noop flag resources are being exported to the db. Is this expected or a bug? Hmm what version of puppet are you using? I've just encountered exactly this with puppet 0.25.4. ran puppet with -t --noop on a node that has yet never run puppet, and it exported a nagios host. I think it's a bug. If you open an issue about it, send the URL here and I'll go vote for it. I would expect it to simulate the transaction with the db... I would too. It could for example warn if there's a conflict (redefinition of an exported resource) but it shouldn't commit resources to database. -- Gabriel Filion -- 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] Solaris mount provider question
On Wed, Jul 13, 2011 at 02:54:07PM -0700, Aaron Grewell wrote:
I'm trying to mount multiple swap partitions in Solaris, but I'm not sure
how to create a working syntax for that. Since the mountpoint for a swap
partition is '-' adding more than one is going to result in a multiple
declaration.
I'd like to do something like this:
mount { '-':
device = '/dev/zvol/dsk/rpool/swap01',
fstype = swap,
atboot = no,
options = -,
}
mount { '-':
device = '/dev/zvol/dsk/upool/swap02',
fstype = swap,
atboot = no,
options = -,
}
I would use the 'path' property, but it's listed as deprecated and I'd
rather not have my manifest break upon upgrading. Is there a better way to
do this that I'm missing?
You cannot manage a mountpoint (here -) twice because puppet uses the
mount point to identify your resource.
(there is an old bug report about your exact same usecase:
http://projects.puppetlabs.com/issues/611)
Let's say there already is a swap entry in /etc/vfstab with device set to
/dev/zvol/dsk/upool/swap03. Is this the first resource and device is
out of sync (is swap03, should be swap01) or should this line match
your second resource and device is out of sync (is swap03, should be
swap02) or should it be treated as a separate resource?
To demonstrate the problem and get rid of duplicate error message you
can set two different resource titles and then set name = '-' on both
resources. But then you have the problem that puppet will constantly mix up
the two resources.
Puppet just needs something to identify a resource and for the mounttype
it is the mount point. You probably can use an exec resource like
exec { '/bin/echo .../swap01... /etc/vfstab':
unless = '/bin/grep .../swap01... /etc/vfstab',
}
exec { '/bin/echo .../swap02... /etc/vfstab':
unless = '/bin/grep .../swap02... /etc/vfstab',
}
Maybe someone else has better ideas?
-Stefan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Open Source Team iteration planning summary 2011-07-13
We've made some good progress on getting Facter Puppet running on Windows. Currently, we have Facter installable and running through install.rb, with all tests passing on Windows Server 2008 R2. We also have Puppet installable through install.rb, and are currently working on getting the code and tests to a passing state. We have explicitly disabled running the master under Windows with an appropriate message stating that it is not supported. We may re-visit this at some point, but for now we're just concerned with getting puppet agent, and puppet apply working on Windows. We've been adding sub-tasks to the meta-ticket (#8268). If you're following along at home, please feel free to bring up any issues you may find on the parent, or any of the appropriate sub-tickets. Completed backlog items: * Explicitly disable master on Windows. * Facter installs on Windows * Facter tests passing on Windows * Puppet installs on Windows * #8356 - Default value of :color should be false on Windows * #7581 - Provide more detailed error message when missing gems on Windows Current backlog: * #8341 - Puppet loading facts repeatedly * Disable tests exclusive to master functionality on Windows * All Puppet tests passing on Windows * #8322 - Facter should return as much info as Windows SystemInfo * #8272 - Windows Services Management * #8414 - Task scheduler type/provider for Windows * #8301 - Red Hat Spec file in 2.7.2rc1 isn't quite right * #8408 - Local user provider for Windows * #8409 - Local group provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] Solaris mount provider question
On 14 July 2011 09:06, Stefan Schulte stefan.schu...@taunusstein.netwrote: On Wed, Jul 13, 2011 at 02:54:07PM -0700, Aaron Grewell wrote: I'm trying to mount multiple swap partitions in Solaris, but I'm not sure how to create a working syntax for that. Since the mountpoint for a swap partition is '-' adding more than one is going to result in a multiple declaration. You cannot manage a mountpoint (here -) twice because puppet uses the mount point to identify your resource. (there is an old bug report about your exact same usecase: http://projects.puppetlabs.com/issues/611) That's the problem - Solaris swap entries in vfstab do not have unique names for the mount point - just a -. I sort of hinted at this in https://projects.puppetlabs.com/issues/6845#note-12 (which Stefan sorted - so he's the guru on this) Puppet just needs something to identify a resource and for the mounttype it is the mount point. You probably can use an exec resource like Maybe someone else has better ideas? I can think of nothing short of modifying the mount provider to accept a different name for the specific case of swap mount entries. Not pretty. Maybe it could be merged into https://projects.puppetlabs.com/issues/7188:-) Regards John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] wrong nodes.pp being accessed by the client
On Wed, Jul 13, 2011 at 11:18 AM, newguy aimanparv...@gmail.com wrote: I have two development environments, main and development and my puppet.conf looks like this: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter pluginsync=false templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [development] modulepath = /etc/puppet/environments/development/modules manifests=/etc/puppet/environments/development/manifests/site.pp I have made nodes.pp for both environments. now when I execute the following on the client: puppetd --test --verbose --environment development it access the nodes.pp in the /etc/puppet/manifests rather than going to /etc/puppet/environments/development/manifests/nodes.pp In my site.pp stored at /etc/puppet/environments/development/manifests/ site.pp I have the following: import 'nodes.pp' How should I make puppet access the correct nodes.pp??? Try: [development] modulepath = /etc/puppet/environments/development/modules manifestdir = /etc/puppet/environments/development/manifests manifests=/etc/puppet/environments/development/manifests/site.pp Thanks, Nan -- 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: What is the best practice to clean up installed components on a node?
What if you specify a resource as being disabled/uninstalled/etc by default? On Jul 13, 2011 9:40 AM, Darrell Fuhriman darr...@garnix.org wrote: I've always thought there should be an implicit X::disabled class that gets included for every host where X isn't included. Then if I create said class, it gets automatically executed on all hosts that don't include X. As it is now, one still has to go through and add X::disabled to every host, which is largely defeating the purpose of having a X::disabled class in the first place. (That purpose, for those not paying attention, is to make sure that things are in a known state, including services *not* running where they shouldn't be.) d. Create a class called sg_node::disabled that inherits sg_node and overrides all of it's resources to undo them. This usually means setting 'ensure =absent' (or 'undef' if applicable) for most resources. For execs, I usually set 'unless = true.' -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
