Oh boy. Puppet is frustrating the heck out of me.
I have this below....
node tst_basenode {
include yum
Package {
require => [
Yumrepo["CentOS-Base"],
Yumrepo["EPEL-Core"],
...
]
}
}
node tst_childnode inherits tst_basenode {
include ldap_client
}
This generally seems to work, making sure that my yum repo''s are in
place before anything else is done. However, I saw that the
yum-priorities rpm was being installed way later, and it needs to be
up there with yum, done initially. So, I added a
package["yum-priorities"] to require=> in that default package
definition in the base node and puppet claimed that it found
dependancy cycles. ARGH!
Actually, if you think about it, there''s no guarantee as to when yum
is installed either. It just happens to already be installed because
this is CentOS, but if it wasn''t installed, yum might get installed
later, which would break everything.
Quite simply, how do I GUARANTEE that my repos are done FIRST followed
by any mandatory packages like yum and yum-priorities?
Doug.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-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
-~----------~----~----~----~------~----~------~--~---
> node tst_basenode { > > include yum > > Package { > require => [ > Yumrepo["CentOS-Base"], > Yumrepo["EPEL-Core"], > ... > ] > } > } > > node tst_childnode inherits tst_basenode { > include ldap_client > } >[snip]> Quite simply, how do I GUARANTEE that my repos are done FIRST followed > by any mandatory packages like yum and yum-priorities? >Disclaimer: I don''t really do RPM based distros, and all this is untested, and I should be fixing dinner. If I were you I''d be writing something like this: class base { package { "yum": ensure => present; "yum-priorities": ensure => present; } yumrepo { "foo": require => Package["yum-whatever-it-depends-on"]; "bar: require => Package["you-get-the-idea"}; } } node default { include base } Note that resources are declared in lower case and references to them are declared with the leading character upcased (so you declare a package but refer to a Package["foo}"]. So declare what you need and then map the relationships. HTH, Julian. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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 10/24/2009 11:25 AM, Douglas Garstang wrote:> > Oh boy. Puppet is frustrating the heck out of me. > I have this below.... > > node tst_basenode { > > include yum > > Package { > require => [ > Yumrepo["CentOS-Base"], > Yumrepo["EPEL-Core"], > ... > ] > } > } > > node tst_childnode inherits tst_basenode { > include ldap_client > } > > This generally seems to work, making sure that my yum repo''s are in > place before anything else is done. However, I saw that the > yum-priorities rpm was being installed way later, and it needs to be > up there with yum, done initially. So, I added a > package["yum-priorities"] to require=> in that default package > definition in the base node and puppet claimed that it found > dependancy cycles. ARGH! > > Actually, if you think about it, there''s no guarantee as to when yum > is installed either. It just happens to already be installed because > this is CentOS, but if it wasn''t installed, yum might get installed > later, which would break everything.I''m fairly certain that yum is considered a core package on CentOS, so you should be able to rely on it being there. Besides, if yum isn''t installed, how do you expect to install it? That said, if you still want your manifest to reflect yum, adding require => undef to the yum package definition may work. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC --~--~---------~--~----~------------~-------~--~----~ 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 general, it seems like the best way to handle "must go first" bootstrap items like that is with environments. (We haven''t gotten there yet, but we''re moving in that direction.) New node comes up in environment bootstrap, where there is a generic definition and 1 class that just grabs the bare minimum to make everything else work. (In our case, that is mostly just the ldap configuration so that future runs find the users they want.) Then they update the puppet config to move to a new environment, and the new environment can ignore all the weird dependencies. On Sat, Oct 24, 2009 at 11:25 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:> > Oh boy. Puppet is frustrating the heck out of me. > I have this below.... > > node tst_basenode { > > include yum > > Package { > require => [ > Yumrepo["CentOS-Base"], > Yumrepo["EPEL-Core"], > ... > ] > } > } > > node tst_childnode inherits tst_basenode { > include ldap_client > } > > This generally seems to work, making sure that my yum repo''s are in > place before anything else is done. However, I saw that the > yum-priorities rpm was being installed way later, and it needs to be > up there with yum, done initially. So, I added a > package["yum-priorities"] to require=> in that default package > definition in the base node and puppet claimed that it found > dependancy cycles. ARGH! > > Actually, if you think about it, there''s no guarantee as to when yum > is installed either. It just happens to already be installed because > this is CentOS, but if it wasn''t installed, yum might get installed > later, which would break everything. > > Quite simply, how do I GUARANTEE that my repos are done FIRST followed > by any mandatory packages like yum and yum-priorities? > > Doug. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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 -~----------~----~----~----~------~----~------~--~---
Disconnect wrote:> In general, it seems like the best way to handle "must go first" > bootstrap items like that is with environments. (We haven''t gotten > there yet, but we''re moving in that direction.) > > New node comes up in environment bootstrap, where there is a generic > definition and 1 class that just grabs the bare minimum to make > everything else work. (In our case, that is mostly just the ldap > configuration so that future runs find the users they want.) Then they > update the puppet config to move to a new environment, and the new > environment can ignore all the weird dependencies.There''s another way, which I think is better: tags. Add the metaparameter ''tag => "bootstrap"'' to those resources that need to be set up first, and set ''tags = bootstrap'' in puppet.conf. Also add an augeas resource that changes puppet.conf to ''tags ='', and add ''tag => "bootstrap"'' to that resource as well. A variation of the above is to not run puppetd in its normal daemon mode. Instead run it from cron, using the command puppetd --tags=bootstrap --onetime; puppetd --onetime And don''t have any tags setting in the config file at all. This is what I use. That way, if I in the future add some more resources that must be run before everything else, those too will be run in the right order. The advantage of using tags instead of environments for this, is that you don''t need to maintain two separate sets of manifests. And you can use environments for testing, production, and so on, instead of "wasting" that feature on ordering. /Bellman --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
ISTR trying that and having the same problems. User depends on class ldap-users. (So in theory, anything that needs a user will require that.) Puppetd bails after grabbing the config with "cannot find user joe" because ldap isn''t set up. (Same using tags.) Users may be a special bug though.. On Wed, Oct 28, 2009 at 12:21 PM, Thomas Bellman <bellman@nsc.liu.se> wrote:> > Disconnect wrote: > >> In general, it seems like the best way to handle "must go first" >> bootstrap items like that is with environments. (We haven''t gotten >> there yet, but we''re moving in that direction.) >> >> New node comes up in environment bootstrap, where there is a generic >> definition and 1 class that just grabs the bare minimum to make >> everything else work. (In our case, that is mostly just the ldap >> configuration so that future runs find the users they want.) Then they >> update the puppet config to move to a new environment, and the new >> environment can ignore all the weird dependencies. > > There''s another way, which I think is better: tags. Add the metaparameter > ''tag => "bootstrap"'' to those resources that need to be set up first, > and set ''tags = bootstrap'' in puppet.conf. Also add an augeas resource > that changes puppet.conf to ''tags ='', and add ''tag => "bootstrap"'' to > that resource as well. > > A variation of the above is to not run puppetd in its normal daemon > mode. Instead run it from cron, using the command > > puppetd --tags=bootstrap --onetime; puppetd --onetime > > And don''t have any tags setting in the config file at all. This is > what I use. That way, if I in the future add some more resources > that must be run before everything else, those too will be run in > the right order. > > The advantage of using tags instead of environments for this, is > that you don''t need to maintain two separate sets of manifests. > And you can use environments for testing, production, and so on, > instead of "wasting" that feature on ordering. > > > /Bellman > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Disconnect top-posted thus:> ISTR trying that and having the same problems. > > User depends on class ldap-users. (So in theory, anything that needs a > user will require that.) Puppetd bails after grabbing the config with > "cannot find user joe" because ldap isn''t set up. (Same using tags.) > Users may be a special bug though..I don''t quite follow you. If I have the following manifest: class ldap-setup { tag "bootstrap" ... } node default { include ldap-setup file { "/tmp/gazonk.del": ensure => file, content => "XYZZY\n", owner => "ldap-user", group => "ldap-group"; } } and run it with # puppet --tags=bootstrap foo.pp it will only try to implement the resources in the ''ldap-setup'' class. The file resource will be ignored, and I won''t get any error saying that "ldap-user" or "ldap-group" doesn''t exist. I just tried it, and it works (although I didn''t actually configure LDAP in my ldap-setup class, but I could definitely verify that I didn''t get any errors about missing users or groups). I suspect you made some error when trying. Please try again! :-) /Bellman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Did exactly that. Got:
root@server19:~# puppetd --test --tags=bootstrap
info: Loading fact dmidecode
...
info: mount[modules]: Mounted
info: mount[plugins]: Mounted
err: Could not create apt-dater@puppet: user apt-dater doesn''t exist
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: user apt-dater
doesn''t exist
If I untag the other modules (leaving just ldap-config, which has the
bootstrap tag) it runs fine.
Running ubuntu 0.24.8-2.
apt-dater@puppet is an ssh key entry:
ssh_authorized_key { "apt-dater@puppet":
ensure => present, type => "ssh-rsa", user =>
"aptdater",
key => "foo",
require => File ["/home/aptdater/.ssh"],
}
(and associated entries to create the home directory and such if it
doesn''t exist.)
Looks like its http://projects.reductivelabs.com/issues/1409
On Thu, Oct 29, 2009 at 6:45 AM, Thomas Bellman <bellman@nsc.liu.se>
wrote:>
> Disconnect top-posted thus:
>
>> ISTR trying that and having the same problems.
>>
>> User depends on class ldap-users. (So in theory, anything that needs a
>> user will require that.) Puppetd bails after grabbing the config with
>> "cannot find user joe" because ldap isn''t set up.
(Same using tags.)
>> Users may be a special bug though..
>
> I don''t quite follow you. If I have the following manifest:
>
> class ldap-setup
> {
> tag "bootstrap"
> ...
> }
>
> node default
> {
> include ldap-setup
> file {
> "/tmp/gazonk.del":
> ensure => file, content => "XYZZY\n",
> owner => "ldap-user", group =>
"ldap-group";
> }
> }
>
> and run it with
>
> # puppet --tags=bootstrap foo.pp
>
> it will only try to implement the resources in the
''ldap-setup'' class.
> The file resource will be ignored, and I won''t get any error
saying
> that "ldap-user" or "ldap-group" doesn''t
exist. I just tried it, and
> it works (although I didn''t actually configure LDAP in my
ldap-setup
> class, but I could definitely verify that I didn''t get any errors
> about missing users or groups).
>
> I suspect you made some error when trying. Please try again! :-)
>
>
> /Bellman
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---