I am noticing sometimes I have to do 2 puppet runs to get all dependencies to fully satisfy and for my system to configure itself at boot time. Most of my environment is completely stateless so its important that everything gets configured at runtime (I am currently doing puppet --test at boot up 2x now). For example I have a yum module that sets yum configs up, but obviously I have other modules that depend on the installation of that yum module in order to use it to install rpms. How do some people deal with ordering of modules to make sure things get run first and foremost? I have read in previous threads of people have dependency issues and I am curious on potential solutions to get around it or to properly architect puppet to "do the right thing". -Chris -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I am using "require" for this problem...like in this case:
file { "/usr/local/bb19c":
recurse => true,
source =>
"puppet://$server/modules/$module/bb19c",
owner => "bb",
group => "bin",
ensure => directory,
require => [ Class["general::groups"],
Class["general::users"]],
}
This is an excerpt of my "BigBrother.pp" which defines a class for the
module "general".
The user bb and group bin are only available if the classes
general::groups and general::user are run first.
Without "require" or "before" puppet seems to run more or
less
randomly through the manifests.
I hope I got your problem right ;)
christian
On 9 Mrz., 14:26, Christopher Johnston <chjoh...@gmail.com>
wrote:> I am noticing sometimes I have to do 2 puppet runs to get all dependencies
> to fully satisfy and for my system to configure itself at boot time. Most
> of my environment is completely stateless so its important that everything
> gets configured at runtime (I am currently doing puppet --test at boot up
2x
> now).
>
> For example I have a yum module that sets yum configs up, but obviously I
> have other modules that depend on the installation of that yum module in
> order to use it to install rpms. How do some people deal with ordering of
> modules to make sure things get run first and foremost? I have read in
> previous threads of people have dependency issues and I am curious on
> potential solutions to get around it or to properly architect puppet to
"do
> the right thing".
>
> -Chris
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Tue, Mar 9, 2010 at 9:26 AM, christian <christian@cust.in> wrote:> I am using "require" for this problem...like in this case:Exactly, if you have all of your dependencies modelled, everything should work in a single run. There may be too much output, but puppet has a --graph option that will output a dependency graph (as you have modelled it) in graphviz dot format, so if you''d like to look for missing relationships, that could be a very useful way to find them. --Michael -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
In addition to "require" statements I like to use tags to narrow down which manifests run. For example, I like to add a "bootstrap" tag that I can run on new boxes to lay down the base configs so that puppet runs better. In my case, this sets up NSS/PAM configuration so users can be found properly by the rest of my puppet configs. -Doug On 03/09/2010 09:26 AM, christian wrote:> I am using "require" for this problem...like in this case: > > file { "/usr/local/bb19c": > recurse => true, > source => "puppet://$server/modules/$module/bb19c", > owner => "bb", > group => "bin", > ensure => directory, > require => [ Class["general::groups"], > Class["general::users"]], > } > This is an excerpt of my "BigBrother.pp" which defines a class for the > module "general". > > The user bb and group bin are only available if the classes > general::groups and general::user are run first. > Without "require" or "before" puppet seems to run more or less > randomly through the manifests. > > I hope I got your problem right ;)
On 03/09/2010 09:54 AM, Michael DeHaan wrote:> On Tue, Mar 9, 2010 at 9:26 AM, christian <christian@cust.in> wrote: >> > I am using "require" for this problem...like in this case: > > Exactly, if you have all of your dependencies modelled, everything > should work in a single run.I''ve found this isn''t the case depending on what you''re affecting in your manifests. For example, making changes to NSS that are required by later puppet manifests can still break as puppet hasn''t taken into account for the new NSS configs and doesn''t know how to find the users. I work around this by using tags to bootstrap my system and then run the rest. tldr: dependencies don''t fix everything -Doug
On Mar 9, 2010, at 5:26 AM, Christopher Johnston wrote:> For example I have a yum module that sets yum configs up, but obviously I have other modules that depend on the installation of that yum module in order to use it to install rpms.I do the same thing with apt. To solve this, I set the files that need to be set at the global dependency for all packages. Here''s an example. Package { require => Exec["post-proxy-update"] } file { "/etc/apt/apt.conf.d/01proxy": owner => root, group => root, mode => 644, source => "puppet:///aptcacher-client/01proxy", } exec { "/usr/bin/apt-get update": alias => "post-proxy-update", subscribe => [ File["/etc/apt/apt.conf.d/01proxy"], File["/etc/apt/sources.list.d/simba.list"] ], require => [ File["/etc/apt/apt.conf.d/01proxy"], File["/etc/apt/sources.list.d/simba.list"] ], refreshonly => true, } file { "/etc/apt/sources.list.d/simba.list": owner => root, group => root, mode => 644, source => "puppet:///local-apt/simba.list", } -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I guess my only gripe here is I have about 2 dozen modules most of install
some form of a pkg from yum. So they all have a direct dependency on my yum
module to do the right thing. I would hate to have to put a require in
every single instance that I call the method to install a pkg. Any ideas on
on how to simplify this to ensure yum is the very first thing that gets
configured on my system?
require => [ Class["yum"],
On Tue, Mar 9, 2010 at 5:51 PM, Patrick <kc7zzv@gmail.com> wrote:
>
> On Mar 9, 2010, at 5:26 AM, Christopher Johnston wrote:
>
> > For example I have a yum module that sets yum configs up, but
obviously I
> have other modules that depend on the installation of that yum module in
> order to use it to install rpms.
>
> I do the same thing with apt. To solve this, I set the files that need to
> be set at the global dependency for all packages. Here''s an
example.
>
> Package { require => Exec["post-proxy-update"] }
>
> file { "/etc/apt/apt.conf.d/01proxy":
> owner => root,
> group => root,
> mode => 644,
> source => "puppet:///aptcacher-client/01proxy",
> }
>
> exec { "/usr/bin/apt-get update":
> alias => "post-proxy-update",
> subscribe => [ File["/etc/apt/apt.conf.d/01proxy"],
> File["/etc/apt/sources.list.d/simba.list"] ],
> require => [ File["/etc/apt/apt.conf.d/01proxy"],
> File["/etc/apt/sources.list.d/simba.list"] ],
> refreshonly => true,
> }
>
> file { "/etc/apt/sources.list.d/simba.list":
> owner => root,
> group => root,
> mode => 644,
> source => "puppet:///local-apt/simba.list",
> }
>
> --
> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Put in a feature question for global dependencies like I hassle people about from time to time! We really do need them for setting some site specific stuff. On Wed, Mar 17, 2010 at 7:35 PM, Christopher Johnston <chjohnst@gmail.com>wrote:> I guess my only gripe here is I have about 2 dozen modules most of install > some form of a pkg from yum. So they all have a direct dependency on my yum > module to do the right thing. I would hate to have to put a require in > every single instance that I call the method to install a pkg. Any ideas on > on how to simplify this to ensure yum is the very first thing that gets > configured on my system? > > require => [ Class["yum"], > > On Tue, Mar 9, 2010 at 5:51 PM, Patrick <kc7zzv@gmail.com> wrote: > >> >> On Mar 9, 2010, at 5:26 AM, Christopher Johnston wrote: >> >> > For example I have a yum module that sets yum configs up, but obviously >> I have other modules that depend on the installation of that yum module in >> order to use it to install rpms. >> >> I do the same thing with apt. To solve this, I set the files that need to >> be set at the global dependency for all packages. Here''s an example. >> >> Package { require => Exec["post-proxy-update"] } >> >> file { "/etc/apt/apt.conf.d/01proxy": >> owner => root, >> group => root, >> mode => 644, >> source => "puppet:///aptcacher-client/01proxy", >> } >> >> exec { "/usr/bin/apt-get update": >> alias => "post-proxy-update", >> subscribe => [ File["/etc/apt/apt.conf.d/01proxy"], >> File["/etc/apt/sources.list.d/simba.list"] ], >> require => [ File["/etc/apt/apt.conf.d/01proxy"], >> File["/etc/apt/sources.list.d/simba.list"] ], >> refreshonly => true, >> } >> >> file { "/etc/apt/sources.list.d/simba.list": >> owner => root, >> group => root, >> mode => 644, >> source => "puppet:///local-apt/simba.list", >> } >> >> -- >> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
The only potential solution I see right now is to put the require in a define (which i have) that will do a require check on the class. I would expect this would add some extensive overhead on ever package run. Sent from my iPhone On Mar 17, 2010, at 9:09 PM, Ashley Penney <apenney@gmail.com> wrote:> Put in a feature question for global dependencies like I hassle > people about from time to time! We really do need them for setting > some site specific stuff. > > On Wed, Mar 17, 2010 at 7:35 PM, Christopher Johnston <chjohnst@gmail.com > > wrote: > I guess my only gripe here is I have about 2 dozen modules most of > install some form of a pkg from yum. So they all have a direct > dependency on my yum module to do the right thing. I would hate to > have to put a require in every single instance that I call the > method to install a pkg. Any ideas on on how to simplify this to > ensure yum is the very first thing that gets configured on my system? > > require => [ Class["yum"], > > On Tue, Mar 9, 2010 at 5:51 PM, Patrick <kc7zzv@gmail.com> wrote: > > On Mar 9, 2010, at 5:26 AM, Christopher Johnston wrote: > > > For example I have a yum module that sets yum configs up, but > obviously I have other modules that depend on the installation of > that yum module in order to use it to install rpms. > > I do the same thing with apt. To solve this, I set the files that > need to be set at the global dependency for all packages. Here''s an > example. > > Package { require => Exec["post-proxy-update"] } > > file { "/etc/apt/apt.conf.d/01proxy": > owner => root, > group => root, > mode => 644, > source => "puppet:///aptcacher-client/01proxy", > } > > exec { "/usr/bin/apt-get update": > alias => "post-proxy-update", > subscribe => [ File["/etc/apt/apt.conf.d/01proxy"], File["/ > etc/apt/sources.list.d/simba.list"] ], > require => [ File["/etc/apt/apt.conf.d/01proxy"], File["/ > etc/apt/sources.list.d/simba.list"] ], > refreshonly => true, > } > > file { "/etc/apt/sources.list.d/simba.list": > owner => root, > group => root, > mode => 644, > source => "puppet:///local-apt/simba.list", > } > > -- > 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
How is that different from the example you''re quoting? Can''t you just put whatever''s in that as a global dependency for Package? On Mar 17, 2010, at 4:35 PM, Christopher Johnston wrote:> I guess my only gripe here is I have about 2 dozen modules most of install some form of a pkg from yum. So they all have a direct dependency on my yum module to do the right thing. I would hate to have to put a require in every single instance that I call the method to install a pkg. Any ideas on on how to simplify this to ensure yum is the very first thing that gets configured on my system? > > require => [ Class["yum"], > > On Tue, Mar 9, 2010 at 5:51 PM, Patrick <kc7zzv@gmail.com> wrote: > > On Mar 9, 2010, at 5:26 AM, Christopher Johnston wrote: > > > For example I have a yum module that sets yum configs up, but obviously I have other modules that depend on the installation of that yum module in order to use it to install rpms. > > I do the same thing with apt. To solve this, I set the files that need to be set at the global dependency for all packages. Here''s an example. > > Package { require => Exec["post-proxy-update"] } > > file { "/etc/apt/apt.conf.d/01proxy": > owner => root, > group => root, > mode => 644, > source => "puppet:///aptcacher-client/01proxy", > } > > exec { "/usr/bin/apt-get update": > alias => "post-proxy-update", > subscribe => [ File["/etc/apt/apt.conf.d/01proxy"], File["/etc/apt/sources.list.d/simba.list"] ], > require => [ File["/etc/apt/apt.conf.d/01proxy"], File["/etc/apt/sources.list.d/simba.list"] ], > refreshonly => true, > } > > file { "/etc/apt/sources.list.d/simba.list": > owner => root, > group => root, > mode => 644, > source => "puppet:///local-apt/simba.list", > } > > -- > 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Mar 17, 2010 at 7:35 PM, Christopher Johnston <chjohnst@gmail.com> wrote:> I guess my only gripe here is I have about 2 dozen modules most of install > some form of a pkg from yum. So they all have a direct dependency on my yum > module to do the right thing. I would hate to have to put a require in > every single instance that I call the method to install a pkg. Any ideas on > on how to simplify this to ensure yum is the very first thing that gets > configured on my system? > require => [ Class["yum"], >What if we taught the yum provider to know about "yum groupinstall" ? That way you could add packages into comps.xml and reference them together, which would also be faster than referencing each one by one. While it would not technically be a ''package'' this might be also a decent workaround solution to the ''yum transactions are not batched'' problem. package { "stuff" ensure => latest, is_group => true, ... } Thoughts? --Michael -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Being able to install yum groups would be a nice value add. Sucks having to
list out 8-9 packages and hope rpm/yum deps get sorted out. But what I am
really griping about though is something like this.
Say you have 2 modules, one called ntpd and one called snmpd. Two totally
different types of configurations because not every system might get ntpd
configured (only my DNS servers do). In each of my manifests they have to
install packages, but both modules have a direct dependency on my yum module
to have been run and successfully setup in order to get packages from the
right repo. It gets a little out of control to have to remember to put a
require for the yum module every time I call a package type.
The only potential work around I can think of is to create a define that
puts the require in place..
define install::pkg($ensure) {
package { $pkg:
ensure => $ensure,
require => Class["yum"]
}
}
On Thu, Mar 18, 2010 at 9:46 AM, Michael DeHaan
<michael@reductivelabs.com>wrote:
> On Wed, Mar 17, 2010 at 7:35 PM, Christopher Johnston
> <chjohnst@gmail.com> wrote:
> > I guess my only gripe here is I have about 2 dozen modules most of
> install
> > some form of a pkg from yum. So they all have a direct dependency on
my
> yum
> > module to do the right thing. I would hate to have to put a require
in
> > every single instance that I call the method to install a pkg. Any
ideas
> on
> > on how to simplify this to ensure yum is the very first thing that
gets
> > configured on my system?
> > require => [ Class["yum"],
> >
>
> What if we taught the yum provider to know about "yum
groupinstall" ?
>
> That way you could add packages into comps.xml and reference them
> together, which would also be faster than referencing each one by one.
>
> While it would not technically be a ''package'' this might
be also a
> decent workaround solution to the ''yum transactions are not
batched''
> problem.
>
> package { "stuff"
> ensure => latest,
> is_group => true,
> ...
> }
>
> Thoughts?
>
> --Michael
>
> --
> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Thu, Mar 18, 2010 at 10:03 AM, Christopher Johnston <chjohnst@gmail.com> wrote:> Being able to install yum groups would be a nice value add. Sucks having to > list out 8-9 packages and hope rpm/yum deps get sorted out. But what I am > really griping about though is something like this.Well, if the packages *do* have proper dependencies, installing one will install the dependencies. I would hope there''s no hoping on that, though it may be you have packages that don''t have good dependencies yet. In that case, fix the packages and that problem goes away :)> Say you have 2 modules, one called ntpd and one called snmpd. Two totally > different types of configurations because not every system might get ntpd > configured (only my DNS servers do). In each of my manifests they have to > install packages, but both modules have a direct dependency on my yum module > to have been run and successfully setup in order to get packages from the > right repo. It gets a little out of control to have to remember to put a > require for the yum module every time I call a package type.Modelling it as a "yum module" seems a little weird to me (though I can see where it would save typing in fairly homogenous environments), I''d think it might work better if you keep the package requirements inside the modules that need them. That is to say, if you have an NTP class/module, require the packages needed for NTP there? --Michael -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Michael DeHaan wrote:> What if we taught the yum provider to know about "yum groupinstall" ? > > That way you could add packages into comps.xml and reference them > together, which would also be faster than referencing each one by one. > > While it would not technically be a ''package'' this might be also a > decent workaround solution to the ''yum transactions are not batched'' > problem. > > package { "stuff" > ensure => latest, > is_group => true, > ... > } > > Thoughts?This might be nice for installs, but what happens when someone wants to remove a group? Using yum groupremove isn''t the inverse of groupinstall. This can easily remove far more than users intend, especially if you don''t realize that groupremove isn''t the exact opposite of groupinstall. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Freedom is actually a bigger game than power, power is about what you can control, freedom is about what you can unleash. -- Harriet Ruben
Majority of the time rpm deps in fedora are good, so thats not that big of a concern. I am just overly anal about stuff where if I install the ldap client I also make sure pam is there also (yet you would expect the rpm dep to satisfy it). Hmm, maybe you are misunderstanding me. The NTPD class/module has the required packages in there, but if my yum.conf is not setup or the class dependency is not defined for it then the pkg install will fail for obvious reasons. So the only way I know how to make every one of my modules (I have over a dozen of them now) that install packages is to make sure they have a direct dependency on the yum class/module to run before. What I want to do is enforce a global dependency perhaps, or a way of ensure that yum is the very first thing that gets setup on my system before any other module is run due to the direct dependency on a proper yum.conf. Make sense now? Because of this direct dependency and no proper ordering with puppet without it, I have to sometimes to do two puppet runs. -Chris On Thu, Mar 18, 2010 at 10:14 AM, Michael DeHaan <michael@reductivelabs.com>wrote:> On Thu, Mar 18, 2010 at 10:03 AM, Christopher Johnston > <chjohnst@gmail.com> wrote: > > Being able to install yum groups would be a nice value add. Sucks having > to > > list out 8-9 packages and hope rpm/yum deps get sorted out. But what I > am > > really griping about though is something like this. > > Well, if the packages *do* have proper dependencies, installing one > will install the dependencies. I would hope there''s no hoping on > that, though it may be you have packages that don''t have good > dependencies yet. In that case, fix the packages and that problem > goes away :) > > > > Say you have 2 modules, one called ntpd and one called snmpd. Two > totally > > different types of configurations because not every system might get ntpd > > configured (only my DNS servers do). In each of my manifests they have > to > > install packages, but both modules have a direct dependency on my yum > module > > to have been run and successfully setup in order to get packages from the > > right repo. It gets a little out of control to have to remember to put a > > require for the yum module every time I call a package type. > > Modelling it as a "yum module" seems a little weird to me (though I > can see where it would save typing in fairly homogenous environments), > I''d think it might work better if you keep the package requirements > inside the modules that need them. That is to say, if you have an > NTP class/module, require the packages needed for NTP there? > > --Michael > > -- > 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Mar 18, 2010 at 7:32 AM, Christopher Johnston <chjohnst@gmail.com> wrote:> Majority of the time rpm deps in fedora are good, so thats not that big of a > concern. I am just overly anal about stuff where if I install the ldap > client I also make sure pam is there also (yet you would expect the rpm dep > to satisfy it). > Hmm, maybe you are misunderstanding me. The NTPD class/module has the > required packages in there, but if my yum.conf is not setup or the class > dependency is not defined for it then the pkg install will fail for obvious > reasons. So the only way I know how to make every one of my modules (I have > over a dozen of them now) that install packages is to make sure they have a > direct dependency on the yum class/module to run before. > What I want to do is enforce a global dependency perhaps, or a way of ensure > that yum is the very first thing that gets setup on my system before any > other module is run due to the direct dependency on a proper yum.conf. Make > sense now? Because of this direct dependency and no proper ordering with > puppet without it, I have to sometimes to do two puppet runs.We set a resource default at the top level of our manifests like this: Package { require => Class["package::apt::update"] } and that class manages it''s own internal dependencies so that before any package is installed, we''re guaranteed to have run: apt-get update apt-get -f install dpkg --configure -a apt-get dist-upgrade Then when it comes to setting up repositories, we do them all with File types in a certain hierarchy, so we set a default at that level of: File { owner => "root", group => "root", mode => 0644, before => Class["package::apt::update"] } so we know that when putting down any new repositories, they will occur before the apt updating class does, and any package installation will occur after that.> -Chris > > On Thu, Mar 18, 2010 at 10:14 AM, Michael DeHaan <michael@reductivelabs.com> > wrote: >> >> On Thu, Mar 18, 2010 at 10:03 AM, Christopher Johnston >> <chjohnst@gmail.com> wrote: >> > Being able to install yum groups would be a nice value add. Sucks >> > having to >> > list out 8-9 packages and hope rpm/yum deps get sorted out. But what I >> > am >> > really griping about though is something like this. >> >> Well, if the packages *do* have proper dependencies, installing one >> will install the dependencies. I would hope there''s no hoping on >> that, though it may be you have packages that don''t have good >> dependencies yet. In that case, fix the packages and that problem >> goes away :) >> >> >> > Say you have 2 modules, one called ntpd and one called snmpd. Two >> > totally >> > different types of configurations because not every system might get >> > ntpd >> > configured (only my DNS servers do). In each of my manifests they have >> > to >> > install packages, but both modules have a direct dependency on my yum >> > module >> > to have been run and successfully setup in order to get packages from >> > the >> > right repo. It gets a little out of control to have to remember to put >> > a >> > require for the yum module every time I call a package type. >> >> Modelling it as a "yum module" seems a little weird to me (though I >> can see where it would save typing in fairly homogenous environments), >> I''d think it might work better if you keep the package requirements >> inside the modules that need them. That is to say, if you have an >> NTP class/module, require the packages needed for NTP there? >> >> --Michael >> >> -- >> 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+unsubscribe@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+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Mar 18, 2010 at 10:25 AM, Todd Zullinger <tmz@pobox.com> wrote:> Michael DeHaan wrote: >> What if we taught the yum provider to know about "yum groupinstall" ? >> >> That way you could add packages into comps.xml and reference them >> together, which would also be faster than referencing each one by one. >> >> While it would not technically be a ''package'' this might be also a >> decent workaround solution to the ''yum transactions are not batched'' >> problem. >> >> package { "stuff" >> ensure => latest, >> is_group => true, >> ... >> } >> >> Thoughts? > > This might be nice for installs, but what happens when someone wants to > remove a group? Using yum groupremove isn''t the inverse of > groupinstall. This can easily remove far more than users intend, > especially if you don''t realize that groupremove isn''t the exact > opposite of groupinstall.Indeed, you almost never want to do "yum groupremove" as you may be removing things that "yum groupinstall" didn''t add. I think it would be a documentation item, with notable skull and crossbones about 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Mar 18, 2010 at 10:32 AM, Christopher Johnston <chjohnst@gmail.com> wrote:> Majority of the time rpm deps in fedora are good, so thats not that big of a > concern. I am just overly anal about stuff where if I install the ldap > client I also make sure pam is there also (yet you would expect the rpm dep > to satisfy it). > Hmm, maybe you are misunderstanding me. The NTPD class/module has the > required packages in there, but if my yum.conf is not setup or the class > dependency is not defined for it then the pkg install will fail for obvious > reasons. So the only way I know how to make every one of my modules (I have > over a dozen of them now) that install packages is to make sure they have a > direct dependency on the yum class/module to run before. > What I want to do is enforce a global dependency perhaps, or a way of ensure > that yum is the very first thing that gets setup on my system before any > other module is run due to the direct dependency on a proper yum.conf. Make > sense now? Because of this direct dependency and no proper ordering with > puppet without it, I have to sometimes to do two puppet runs.I haven''t tried it yet, but ... Package { require +> Class[''yum''] } And in there you include the yum configuration for /etc/yum.repos.d/ ?> -Chris > > On Thu, Mar 18, 2010 at 10:14 AM, Michael DeHaan <michael@reductivelabs.com> > wrote: >> >> On Thu, Mar 18, 2010 at 10:03 AM, Christopher Johnston >> <chjohnst@gmail.com> wrote: >> > Being able to install yum groups would be a nice value add. Sucks >> > having to >> > list out 8-9 packages and hope rpm/yum deps get sorted out. But what I >> > am >> > really griping about though is something like this. >> >> Well, if the packages *do* have proper dependencies, installing one >> will install the dependencies. I would hope there''s no hoping on >> that, though it may be you have packages that don''t have good >> dependencies yet. In that case, fix the packages and that problem >> goes away :) >> >> >> > Say you have 2 modules, one called ntpd and one called snmpd. Two >> > totally >> > different types of configurations because not every system might get >> > ntpd >> > configured (only my DNS servers do). In each of my manifests they have >> > to >> > install packages, but both modules have a direct dependency on my yum >> > module >> > to have been run and successfully setup in order to get packages from >> > the >> > right repo. It gets a little out of control to have to remember to put >> > a >> > require for the yum module every time I call a package type. >> >> Modelling it as a "yum module" seems a little weird to me (though I >> can see where it would save typing in fairly homogenous environments), >> I''d think it might work better if you keep the package requirements >> inside the modules that need them. That is to say, if you have an >> NTP class/module, require the packages needed for NTP there? >> >> --Michael >> >> -- >> 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> We set a resource default at the top level of our manifests like this: > > Package { require => Class["package::apt::update"] }Beat me to it :)> > and that class manages it''s own internal dependencies so that before > any package is installed, we''re guaranteed to have run: > > apt-get update > apt-get -f install > dpkg --configure -a > apt-get dist-upgrade > > Then when it comes to setting up repositories, we do them all with > File types in a certain hierarchy, so we set a default at that level > of: > > File { owner => "root", group => "root", mode => 0644, before => > Class["package::apt::update"] } > > so we know that when putting down any new repositories, they will > occur before the apt updating class does, and any package installation > will occur after that. > > > > >> -Chris >> >> On Thu, Mar 18, 2010 at 10:14 AM, Michael DeHaan <michael@reductivelabs.com> >> wrote: >>> >>> On Thu, Mar 18, 2010 at 10:03 AM, Christopher Johnston >>> <chjohnst@gmail.com> wrote: >>> > Being able to install yum groups would be a nice value add. Sucks >>> > having to >>> > list out 8-9 packages and hope rpm/yum deps get sorted out. But what I >>> > am >>> > really griping about though is something like this. >>> >>> Well, if the packages *do* have proper dependencies, installing one >>> will install the dependencies. I would hope there''s no hoping on >>> that, though it may be you have packages that don''t have good >>> dependencies yet. In that case, fix the packages and that problem >>> goes away :) >>> >>> >>> > Say you have 2 modules, one called ntpd and one called snmpd. Two >>> > totally >>> > different types of configurations because not every system might get >>> > ntpd >>> > configured (only my DNS servers do). In each of my manifests they have >>> > to >>> > install packages, but both modules have a direct dependency on my yum >>> > module >>> > to have been run and successfully setup in order to get packages from >>> > the >>> > right repo. It gets a little out of control to have to remember to put >>> > a >>> > require for the yum module every time I call a package type. >>> >>> Modelling it as a "yum module" seems a little weird to me (though I >>> can see where it would save typing in fairly homogenous environments), >>> I''d think it might work better if you keep the package requirements >>> inside the modules that need them. That is to say, if you have an >>> NTP class/module, require the packages needed for NTP there? >>> >>> --Michael >>> >>> -- >>> 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+unsubscribe@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+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Yup the yum manifest sets up my configuration files for the various repos
(ie, we have a development repos for our lab that only goes on lab systems
and production hosts the production repo).
Package { require => Class["yum::base"] }
I guess I could put that in every manifest at the top that is doing package
installs. Is there one place I could put this so it applies to ALL modules,
perhaps site.pp?
-Chris
On Thu, Mar 18, 2010 at 11:43 AM, Michael DeHaan
<michael@reductivelabs.com>wrote:
> On Thu, Mar 18, 2010 at 10:32 AM, Christopher Johnston
> <chjohnst@gmail.com> wrote:
> > Majority of the time rpm deps in fedora are good, so thats not that
big
> of a
> > concern. I am just overly anal about stuff where if I install the
ldap
> > client I also make sure pam is there also (yet you would expect the
rpm
> dep
> > to satisfy it).
> > Hmm, maybe you are misunderstanding me. The NTPD class/module has the
> > required packages in there, but if my yum.conf is not setup or the
class
> > dependency is not defined for it then the pkg install will fail for
> obvious
> > reasons. So the only way I know how to make every one of my modules
(I
> have
> > over a dozen of them now) that install packages is to make sure they
have
> a
> > direct dependency on the yum class/module to run before.
> > What I want to do is enforce a global dependency perhaps, or a way of
> ensure
> > that yum is the very first thing that gets setup on my system before
any
> > other module is run due to the direct dependency on a proper yum.conf.
> Make
> > sense now? Because of this direct dependency and no proper ordering
with
> > puppet without it, I have to sometimes to do two puppet runs.
>
> I haven''t tried it yet, but ...
>
> Package {
> require +> Class[''yum'']
> }
>
> And in there you include the yum configuration for /etc/yum.repos.d/ ?
>
>
>
>
> > -Chris
> >
> > On Thu, Mar 18, 2010 at 10:14 AM, Michael DeHaan <
> michael@reductivelabs.com>
> > wrote:
> >>
> >> On Thu, Mar 18, 2010 at 10:03 AM, Christopher Johnston
> >> <chjohnst@gmail.com> wrote:
> >> > Being able to install yum groups would be a nice value add.
Sucks
> >> > having to
> >> > list out 8-9 packages and hope rpm/yum deps get sorted out.
But what
> I
> >> > am
> >> > really griping about though is something like this.
> >>
> >> Well, if the packages *do* have proper dependencies, installing
one
> >> will install the dependencies. I would hope there''s no
hoping on
> >> that, though it may be you have packages that don''t have
good
> >> dependencies yet. In that case, fix the packages and that
problem
> >> goes away :)
> >>
> >>
> >> > Say you have 2 modules, one called ntpd and one called snmpd.
Two
> >> > totally
> >> > different types of configurations because not every system
might get
> >> > ntpd
> >> > configured (only my DNS servers do). In each of my manifests
they
> have
> >> > to
> >> > install packages, but both modules have a direct dependency
on my yum
> >> > module
> >> > to have been run and successfully setup in order to get
packages from
> >> > the
> >> > right repo. It gets a little out of control to have to
remember to
> put
> >> > a
> >> > require for the yum module every time I call a package type.
> >>
> >> Modelling it as a "yum module" seems a little weird to
me (though I
> >> can see where it would save typing in fairly homogenous
environments),
> >> I''d think it might work better if you keep the package
requirements
> >> inside the modules that need them. That is to say, if you have
an
> >> NTP class/module, require the packages needed for NTP there?
> >>
> >> --Michael
> >>
> >> --
> >> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Thu, Mar 18, 2010 at 8:49 AM, Christopher Johnston <chjohnst@gmail.com> wrote:> Yup the yum manifest sets up my configuration files for the various repos > (ie, we have a development repos for our lab that only goes on lab systems > and production hosts the production repo). > > Package { require => Class["yum::base"] } > > I guess I could put that in every manifest at the top that is doing package > installs. Is there one place I could put this so it applies to ALL modules, > perhaps site.pp?Yep. Either put it in site.pp (although you may want to match $operatingsystem or something) or some parent class that includes your other classes. Our site.pp looks like: node default { include base } and our base module/class includes all the other ones, so we set it in modules/base/manifests/init.pp (actually we set it in class base::debian and base::mac and base::solaris for our different platforms) -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
What is the best way to map out all my depencies (is there a way to chart them somehow?) I am finding no matter how many places I put notifies, requires, etc. I still end up having to two 2-3 runs of puppet. Very frustrating. On Thu, Mar 18, 2010 at 11:57 AM, Nigel Kersten <nigelk@google.com> wrote:> On Thu, Mar 18, 2010 at 8:49 AM, Christopher Johnston > <chjohnst@gmail.com> wrote: > > Yup the yum manifest sets up my configuration files for the various repos > > (ie, we have a development repos for our lab that only goes on lab > systems > > and production hosts the production repo). > > > > Package { require => Class["yum::base"] } > > > > I guess I could put that in every manifest at the top that is doing > package > > installs. Is there one place I could put this so it applies to ALL > modules, > > perhaps site.pp? > > Yep. Either put it in site.pp (although you may want to match > $operatingsystem or something) or some parent class that includes your > other classes. > > Our site.pp looks like: > > node default { include base } > > and our base module/class includes all the other ones, so we set it in > modules/base/manifests/init.pp > > (actually we set it in class base::debian and base::mac and > base::solaris for our different platforms) > > -- > 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 9 April 2010 08:35, Christopher Johnston <chjohnst@gmail.com> wrote:> What is the best way to map out all my depencies (is there a way to chart > them somehow?) I am finding no matter how many places I put notifies, > requires, etc. I still end up having to two 2-3 runs of puppet. Very > frustrating. >From the FAQ (which is a little in flux at the moment): How do I use Puppet’s graphing support? Puppet has graphing support capable of creating graph files of your Puppet client configurations. The graphs are created by and on the client, so you must enable the graph option. This will create files in dot format in the client’s graphdir directory; these files are text files and need to be interpreted by another application to get turned into images. The easiest way to do this is to use OmniGraffle, since it automatically converts them to attractive graphs, but it only runs on OS X. You can also install graphviz, which comes with the dot application, which you can use to turn the text files into images: dot -Tpng /var/puppet/state/graphs/resources.dot -o /tmp/configuration.png 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.