Hi, I''ve the following class to manage the root password in our servers. class root_user_private_servers { user { "root": ensure=>"present", uid=>"0", gid=>"0", comment=>"root", shell=>"/bin/bash", home=>"/root", managehome=>"false", allowdupe=>"false", password => $operatingsystem ? { debian => $lsbdistcodename ? { default => ''hashXXXXXXXXXXXXXX'', lenny => ''hashXXXXXXXXXXXXXX'', etch => ''hashXXXXXXXXXXXXXX'', sarge => ''hashXXXXXXXXXXXXXX'', }, default => ''hashXXXXXXXXXXXXXX'', }; } } When I run the class in this way without stages and the package lsb- release it''s installed it works correctly. class testA { include root_user_private_servers } node ''debian-lenny.XXXXX.XXXX'' { include testA } The problem it''s that when I run the class with stages it fails with a dependency cicle. The class apt_official it set the Debian repos and doesn''t "require" or "include any other class, it doesn''t have dependencies. The class lsb-release install the packages lsb_release, this it''s because I use the facter variable $lsbdistcodename to distinguish between Debian versions only in the class root_user_private_servers. The idea it''s to setup the Debian repositories first, then install the lsb_release package and the run all the others manifests. stage {"first": before=>Stage["second"]} stage {"second": before=>Stage["main"]} class { "compulsory_main1": stage=> first} class compulsory_main1 { include apt_official } class { "compulsory_main2": stage=> second} class compulsory_main2 { include lsb_release } class testA { include root_user_private_servers } I''ve also tried this one: class testA inherits compulsory_main2 {....} this one class testA { include compulsory_main1 include compulsory_main2 include root_user_private_servers } and this one class testA { require compulsory_main1 require compulsory_main2 include root_user_private_servers } with no luck, Can you help me to solve this problem? Thanks in advance. -- 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 Apr 15, 2:32 am, ikkaro <isaak.gonza...@gmail.com> wrote:> The problem it''s that when I run the class with stages it fails with a > dependency cicle.Which is? The --debug output showing the cycle and all the autorequires would be helpful here.> The class apt_official it set the Debian repos and doesn''t "require" > or "include any other class, it doesn''t have dependencies. > > The class lsb-release install the packages lsb_release, this it''s > because I use the facter variable $lsbdistcodename to distinguish > between Debian versions only in the class root_user_private_servers.That''s not going to do what you want, dependency issues notwithstanding. Nodes posts all their facts to the server before their manifest is compiled, so causing the lsb_release package to be installed early in a Puppet run will not make the $lsbdistcodename fact available later in the same run. Run stages partition a run into stages, not into separate runs; there is no re-posting of facts between stages.> The idea it''s to setup the Debian repositories first, then install the > lsb_release package and the run all the others manifests.Run stages can, in principle, give you that ordering. For what it''s worth, I personally would use only one preliminary stage, with ordinary resource dependencies establishing the application order of the resources in that stage. That wouldn''t make any difference in your dependency cycle, though.> stage {"first": before=>Stage["second"]} > stage {"second": before=>Stage["main"]} > > class { "compulsory_main1": stage=> first} > class compulsory_main1 > { > include apt_official > > } > > class { "compulsory_main2": stage=> second} > class compulsory_main2 > { > include lsb_release > > }That''s a strange way to do it. Why are you not doing this: class { "apt-official": stage => first } class { "lsb_release": stage => second } ? I suspect that the way you showed above puts only the wrapper classes into the specified stages, not the wrapped ones. That could impact your dependencies. Why do you need wrapper classes?> class testA > { > include root_user_private_servers > > } > > I''ve also tried this one: > class testA inherits compulsory_main2 {....}Class inheritance is not the answer to this problem. Use it ONLY to override resource properties, and override resource properties only when you have no better alternative.> this one > > class testA { > include compulsory_main1 > include compulsory_main2 > include root_user_private_servers > } > > and this one > > class testA { > require compulsory_main1 > require compulsory_main2 > include root_user_private_servers > }The relative order of include and/or require statements is not a reliable method to influence ordering, and it certainly does not affect explicit dependencies, so this is also the wrong direction. We can probably help you work out the dependency problem if you give us more information. Again, however, this approach is not going to get you where you want to be. As an alternative, you could use conditional logic to get what you want across two Puppet runs, and even to get the second one to commence soon after the first finishes. Good luck, 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> The problem it''s that when I run the class with stages it fails with a >> dependency cicle.I have a similar problem as the OP of this thread. When i deploy run stages to have the class "yum" in the pre stage, it works fine untill i "realize" the root user: realize( User["root"], Ssh_authorized_key["root"], ) Enabling the above line causes the dep cycles as seen in attached puppet_depcycle.txt When i remove the realize statement, everything works fine. Also, when i remove run stages it works fine too. What could cause this, and how would i go about to debug this further? Regards Alex -- 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''ve solved the lsb-release problem in this way: $temp_version=$operatingsystemrelease $major_version=regsubst($temp_version,''^(\d+).*$'',''\1'') case $operatingsystem { debian: { case $major_version { 6: { $distro_codename="squeeze" include apt_official::debian_generic_sources include apt_official::apt_keys include apt_official::apt_requirements } 5: { $distro_codename="lenny" include apt_official::debian_generic_sources include apt_official::apt_keys include apt_official::apt_requirements } } } class apt_official::apt_requirements { case $operatingsystem { default: { package { "lsb-release": ensure => installed, require=>Class["apt_official::debian_generic_sources"]; } } } } On the other hand I have problems managing the user root password, if I run this manifest it works fine: class root_user_private_servers { user { "test": ensure=>"present", uid=>"1010", gid=>"50", comment=>"test", shell=>"/bin/bash", home=>"/home/test", managehome=>"false", allowdupe=>"false", password=> ''hashXXXXX'', require => Class["apt_official::apt_requirements"]; } } But if I change the username to root, for example: class root_user_private_servers { user { "root": ensure=>"present", uid=>"0", gid=>"0", comment=>"root", shell=>"/bin/bash", home=>"/root", managehome=>"false", allowdupe=>"false", password=> ''hash'', require => Class["apt_official::apt_requirements"]; } } I get the next error, err: Could not apply complete catalog: Found dependency cycles in the following relationships: User[root] => File[/etc/apt/sources.list.d], File[/etc/apt/sources.list.d] => File[/etc/apt/sources.list.d/00- official.sources.list], User[root] => File[/etc/apt/sources.list.d/00- official.sources.list], File[/etc/apt/sources.list.d] => Package[lsb- release], File[/etc/apt/sources.list.d/00-official.sources.list] => Package[lsb-release], File[/etc/apt/sources.list.d/01- security.sources.list] => Package[lsb-release], Exec[aptitude update] => Package[lsb-release], Exec[aptitude clean] => Package[lsb-release], Package[lsb-release] => User[root], File[/etc/apt/sources.list.d] => File[/etc/apt/sources.list.d/01-security.sources.list], User[root] => File[/etc/apt/sources.list.d/01-security.sources.list], File[/etc/apt/ sources.list.d/00-official.sources.list] => Exec[aptitude update], File[/etc/apt/sources.list.d/01-security.sources.list] => Exec[aptitude update], File[/etc/apt/sources.list.d/00- official.sources.list] => Exec[aptitude clean], File[/etc/apt/ sources.list.d/01-security.sources.list] => Exec[aptitude clean] I''ve used the next configuration: In templates.pp class testA { include apt_official include root_user_private_servers } In nodes.pp node ''debian-lenny.es.clara.net'' { include testA } Please let my know if you need more info, it seems that there''re some dependency problem managing the root user. Thanks in advance. On 18 abr, 09:36, Alexander Bien <ab...@nbmc.de> wrote:> >> The problem it''s that when I run the class with stages it fails with a > >> dependency cicle. > > I have a similar problem as the OP of this thread. When i deploy run > stages to have the class "yum" in the pre stage, it works fine untill i > "realize" the root user: > > realize( > User["root"], > Ssh_authorized_key["root"], > ) > > Enabling the above line causes the dep cycles as seen in attached > puppet_depcycle.txt > > When i remove the realize statement, everything works fine. > > Also, when i remove run stages it works fine too. > > What could cause this, and how would i go about to debug this further? > > Regards > Alex > > puppet_depcycle.txt > 61 KVerDescargar > > puppet_no_depcycle.txt > 11 KVerDescargar-- 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''ve solved the lsb-release problem in this way: $temp_version=$operatingsystemrelease $major_version=regsubst($temp_version,''^(\d+).*$'',''\1'') case $operatingsystem { debian: { case $major_version { 6: { $distro_codename="squeeze" include apt_official::debian_generic_sources include apt_official::apt_keys include apt_official::apt_requirements } 5: { $distro_codename="lenny" include apt_official::debian_generic_sources include apt_official::apt_keys include apt_official::apt_requirements } } } class apt_official::apt_requirements { case $operatingsystem { default: { package { "lsb-release": ensure => installed, require=>Class["apt_official::debian_generic_sources"]; } } } } On the other hand I have problems managing the user root password, if I run this manifest it works fine: class root_user_private_servers { user { "test": ensure=>"present", uid=>"1010", gid=>"50", comment=>"test", shell=>"/bin/bash", home=>"/home/test", managehome=>"false", allowdupe=>"false", password=> ''hashXXXXX'', require => Class["apt_official::apt_requirements"]; } } But if I change the username to root, for example: class root_user_private_servers { user { "root": ensure=>"present", uid=>"0", gid=>"0", comment=>"root", shell=>"/bin/bash", home=>"/root", managehome=>"false", allowdupe=>"false", password=> ''hash'', require => Class["apt_official::apt_requirements"]; } } I get the next error, err: Could not apply complete catalog: Found dependency cycles in the following relationships: User[root] => File[/etc/apt/sources.list.d], File[/etc/apt/sources.list.d] => File[/etc/apt/sources.list.d/00- official.sources.list], User[root] => File[/etc/apt/sources.list.d/00- official.sources.list], File[/etc/apt/sources.list.d] => Package[lsb- release], File[/etc/apt/sources.list.d/00-official.sources.list] => Package[lsb-release], File[/etc/apt/sources.list.d/01- security.sources.list] => Package[lsb-release], Exec[aptitude update] => Package[lsb-release], Exec[aptitude clean] => Package[lsb-release], Package[lsb-release] => User[root], File[/etc/apt/sources.list.d] => File[/etc/apt/sources.list.d/01-security.sources.list], User[root] => File[/etc/apt/sources.list.d/01-security.sources.list], File[/etc/apt/ sources.list.d/00-official.sources.list] => Exec[aptitude update], File[/etc/apt/sources.list.d/01-security.sources.list] => Exec[aptitude update], File[/etc/apt/sources.list.d/00- official.sources.list] => Exec[aptitude clean], File[/etc/apt/ sources.list.d/01-security.sources.list] => Exec[aptitude clean] I''ve used the next configuration: In templates.pp class testA { include apt_official include root_user_private_servers } In nodes.pp node ''debian-lenny.es.clara.net'' { include testA } Please let my know if you need more info, it seems that there''re some dependency problem managing the root user. Thanks in advance. On 18 abr, 09:36, Alexander Bien <ab...@nbmc.de> wrote:> >> The problem it''s that when I run the class with stages it fails with a > >> dependency cicle. > > I have a similar problem as the OP of this thread. When i deploy run > stages to have the class "yum" in the pre stage, it works fine untill i > "realize" the root user: > > realize( > User["root"], > Ssh_authorized_key["root"], > ) > > Enabling the above line causes the dep cycles as seen in attached > puppet_depcycle.txt > > When i remove the realize statement, everything works fine. > > Also, when i remove run stages it works fine too. > > What could cause this, and how would i go about to debug this further? > > Regards > Alex > > puppet_depcycle.txt > 61 KVerDescargar > > puppet_no_depcycle.txt > 11 KVerDescargar-- 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 Apr 18, 2:36 am, Alexander Bien <ab...@nbmc.de> wrote:> >> The problem it''s that when I run the class with stages it fails with a > >> dependency cicle. > > I have a similar problem as the OP of this thread. When i deploy run > stages to have the class "yum" in the pre stage, it works fine untill i > "realize" the root user: > > realize( > User["root"], > Ssh_authorized_key["root"], > ) > > Enabling the above line causes the dep cycles as seen in attached > puppet_depcycle.txt > > When i remove the realize statement, everything works fine. > > Also, when i remove run stages it works fine too.Then why are you using run stages? I''m serious: what problem do you hope run stages will solve for you?> What could cause this, and how would i go about to debug this further?It arises at least because you are managing a root-owned file that is assigned to an earlier run stage than the one to which the User["root"] resource is assigned. It may not be explicit -- it is possible that one or more of the resources you declare are causing additional resources to be declared and managed. I haven''t made my way all the way through the enormous cyle listing, but here, at least, is one cycle: User[root] => File[/etc/yum/yum.conf], File[/etc/yum/yum.conf] => User[root]. Knowledge that the cycle was only reported when you realized User["root"] helped me narrow my search by looking only at dependencies involving that user. I was lucky that there is a cycle involving only two resources; if the minimum cycle length had been four or more then the cycle would have been much harder to find. If you are going to manage user root (not unambiguously a good idea) then you really ought to do it in the earliest run stage, because everything depends directly or indirectly on root. Also, I would be very surprised if it were not the class that *declares* a virtual resource, not the one(s) that realizes it, that determines to which run stage that resource is assigned. If you assumed the other way around then it might have contributed to putting User["root"] in the wrong stage. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I too am having problems with using stages while managing the root user in a resource. The errors I am getting which spit out the resource relationships reflect a <pre_stage_resource> => User[root] and User[root] => <pre_stage_resource> pair. There must be something implicit about managing user "root" such that nearly all other resources depend on it. I suppose this can be gotten around by managing the root user''s properties in other ways (i.e. with nasty execs and what not), but I think it''s reasonable to expect that many Puppet users, like myself and those in this thread, would like to use a normal User resource in keeping with Puppet principles. Another solution I guess is to always put the root user resource in the earliest stage -- probably what I will end up doing. For that matter, one''s entire user/account class may be put in the pre stage. -Kent On Apr 18, 11:15 am, jcbollinger <John.Bollin...@stJude.org> wrote:> On Apr 18, 2:36 am, Alexander Bien <ab...@nbmc.de> wrote: > > > > > > > > > > > >> The problem it''s that when I run the class with stages it fails with a > > >>dependencycicle. > > > I have a similar problem as the OP of this thread. When i deploy run > > stages to have the class "yum" in the pre stage, it works fine untill i > > "realize" therootuser: > > > realize( > > User["root"], > > Ssh_authorized_key["root"], > > ) > > > Enabling the above line causes the dep cycles as seen in attached > > puppet_depcycle.txt > > > When i remove the realize statement, everything works fine. > > > Also, when i remove run stages it works fine too. > > Then why are you using run stages? I''m serious: what problem do you > hope run stages will solve for you? > > > What could cause this, and how would i go about to debug this further? > > It arises at least because you are managing aroot-owned file that is > assigned to an earlier run stage than the one to which theUser["root"] resource is assigned. It may not be explicit -- it is > possible that one or more of the resources you declare are causing > additional resources to be declared and managed. > > I haven''t made my way all the way through the enormous cyle listing, > but here, at least, is one cycle: > > User[root] => File[/etc/yum/yum.conf], File[/etc/yum/yum.conf] =>User[root]. > > Knowledge that the cycle was only reported when you realizedUser["root"] helped me narrow my search by looking only at > dependencies involving thatuser. I was lucky that there is a cycle > involving only two resources; if the minimum cycle length had been > four or more then the cycle would have been much harder to find. > > If you are going to manageuserroot(not unambiguously a good idea) > then you really ought to do it in the earliest run stage, because > everything depends directly or indirectly onroot. > > Also, I would be very surprised if it were not the class that > *declares* a virtual resource, not the one(s) that realizes it, that > determines to which run stage that resource is assigned. If you > assumed the other way around then it might have contributed to puttingUser["root"] in the wrong stage. > > 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, May 18, 2011 at 10:26 PM, Kent <kentmshultz@gmail.com> wrote:> I too am having problems with using stages while managing the root > user in a resource. The errors I am getting which spit out the > resource relationships reflect a <pre_stage_resource> => User[root] > and User[root] => <pre_stage_resource> pair. > > There must be something implicit about managing user "root" such that > nearly all other resources depend on it. I suppose this can be gotten > around by managing the root user''s properties in other ways (i.e. with > nasty execs and what not), but I think it''s reasonable to expect that > many Puppet users, like myself and those in this thread, would like to > use a normal User resource in keeping with Puppet principles.If a file is owned by a user/group and that user/group resource is declared, then there''s an implicit dependency. So file { ''/foo": require => file, owner => root, # implies require => User[''root''] if root user resource is declared. }> Another solution I guess is to always put the root user resource in > the earliest stage -- probably what I will end up doing. For that > matter, one''s entire user/account class may be put in the pre stage.So yes you can use a normal puppet resource for root, but root user should be in the first stage. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.