A little background: I''m using puppet to manage the configurations of a
group of linux vservers running Ubuntu Lucid. Ubuntu has switched to
using upstart for their boot process; unfortunately there are some
peculiar interactions with vservers which causes openssh to hang during
upgrade, so I need to remove the upstart init script for openssh and
revert back to the sysvrc script instead. Since this needs to happen
before any openssh upgrade, I''ve tried putting the code that does this
into a class that will be run first, like this:
class disable_upstart_for_sshd {
file {
''/etc/init/ssh.conf'':
ensure => absent
}
exec {
''/usr/sbin/update-rc.d ssh defaults'':
creates => ''/etc/rc3.d/S20ssh''
}
}
stage { "pre": before => Stage[main] }
class {
disable_upstart_for_sshd'': stage => pre;
}
Now, if /etc/init/ssh.conf exists, puppet will correctly remove it and
the run will complete without error, but on the *next* and all
subsequent puppet runs I get a long dependency cycle error.
If /etc/init/ssh.conf does not exist, I get no errors (on multiple
runs).
If I remove the run stage code, I get no errors (on multiple runs).
There are no explicit references to /etc/init/ssh.conf in any other
modules (it''s owned by the openssh-server package).
So, is this a bug?
--
Dan Urist
durist@ucar.edu
303-497-2459
--
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 Jan 28, 2011, at 9:28 AM, Dan Urist wrote:> Now, if /etc/init/ssh.conf exists, puppet will correctly remove it and > the run will complete without error, but on the *next* and all > subsequent puppet runs I get a long dependency cycle error. > > If /etc/init/ssh.conf does not exist, I get no errors (on multiple > runs). > > If I remove the run stage code, I get no errors (on multiple runs). > > There are no explicit references to /etc/init/ssh.conf in any other > modules (it''s owned by the openssh-server package).This shouldn''t be possible. The dependencies should be calculated before puppet even checks if that file exists. I would first doublecheck to make sure you aren''t changing puppet''s environment with the first run or using a custom fact that changes depending on that file. If you''re right though, this really is a bug. -- 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 Fri, 28 Jan 2011 09:58:31 -0800 Patrick <kc7zzv@gmail.com> wrote:> > On Jan 28, 2011, at 9:28 AM, Dan Urist wrote: > > > Now, if /etc/init/ssh.conf exists, puppet will correctly remove it > > and the run will complete without error, but on the *next* and all > > subsequent puppet runs I get a long dependency cycle error. > > > > If /etc/init/ssh.conf does not exist, I get no errors (on multiple > > runs). > > > > If I remove the run stage code, I get no errors (on multiple runs). > > > > There are no explicit references to /etc/init/ssh.conf in any other > > modules (it''s owned by the openssh-server package). > > This shouldn''t be possible. The dependencies should be calculated > before puppet even checks if that file exists. > > I would first doublecheck to make sure you aren''t changing puppet''s > environment with the first run or using a custom fact that changes > depending on that file.I don''t have any custom facts; not sure what you mean by changing the environment, though? -- Dan Urist durist@ucar.edu 303-497-2459 -- 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 entered a bug for this: http://projects.puppetlabs.com/issues/6064 On Fri, 28 Jan 2011 11:01:53 -0700 Dan Urist <durist@ucar.edu> wrote:> On Fri, 28 Jan 2011 09:58:31 -0800 > Patrick <kc7zzv@gmail.com> wrote: > > > > > On Jan 28, 2011, at 9:28 AM, Dan Urist wrote: > > > > > Now, if /etc/init/ssh.conf exists, puppet will correctly remove it > > > and the run will complete without error, but on the *next* and all > > > subsequent puppet runs I get a long dependency cycle error. > > > > > > If /etc/init/ssh.conf does not exist, I get no errors (on multiple > > > runs). > > > > > > If I remove the run stage code, I get no errors (on multiple > > > runs). > > > > > > There are no explicit references to /etc/init/ssh.conf in any > > > other modules (it''s owned by the openssh-server package). > > > > This shouldn''t be possible. The dependencies should be calculated > > before puppet even checks if that file exists. > > > > I would first doublecheck to make sure you aren''t changing puppet''s > > environment with the first run or using a custom fact that changes > > depending on that file. > > I don''t have any custom facts; not sure what you mean by changing the > environment, though? >-- Dan Urist durist@ucar.edu 303-497-2459 -- 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 Fri, Jan 28, 2011 at 9:28 AM, Dan Urist <durist@ucar.edu> wrote:> A little background: I''m using puppet to manage the configurations of a > group of linux vservers running Ubuntu Lucid. Ubuntu has switched to > using upstart for their boot process; unfortunately there are some > peculiar interactions with vservers which causes openssh to hang during > upgrade, so I need to remove the upstart init script for openssh and > revert back to the sysvrc script instead. Since this needs to happen > before any openssh upgrade, I''ve tried putting the code that does this > into a class that will be run first, like this: > > class disable_upstart_for_sshd { > file { > ''/etc/init/ssh.conf'': > ensure => absent > } > exec { > ''/usr/sbin/update-rc.d ssh defaults'': > creates => ''/etc/rc3.d/S20ssh'' > } > } > > stage { "pre": before => Stage[main] } > class { > disable_upstart_for_sshd'': stage => pre; > } > > Now, if /etc/init/ssh.conf exists, puppet will correctly remove it and > the run will complete without error, but on the *next* and all > subsequent puppet runs I get a long dependency cycle error. > > If /etc/init/ssh.conf does not exist, I get no errors (on multiple > runs). > > If I remove the run stage code, I get no errors (on multiple runs). > > There are no explicit references to /etc/init/ssh.conf in any other > modules (it''s owned by the openssh-server package). > > So, is this a bug?This does not appear to be a bug. There''s an implicit dependency for the file /etc/init/ssh.conf on file resource /etc/init. File /etc/init is in stage main, and File /etc/init/ssh.conf in in stage pre which cause a dependency loop. In this case, I would simply make the ssh package depend on the changes you''ve implemented. package { "ssh": ensure => latest, require => Class["disable_upstart_for_sshd"], } 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, 28 Jan 2011 11:13:18 -0800 Nan Liu <nan@puppetlabs.com> wrote:> This does not appear to be a bug. There''s an implicit dependency for > the file /etc/init/ssh.conf on file resource /etc/init. File /etc/init > is in stage main, and File /etc/init/ssh.conf in in stage pre which > cause a dependency loop. In this case, I would simply make the ssh > package depend on the changes you''ve implemented. > > package { "ssh": > ensure => latest, > require => Class["disable_upstart_for_sshd"], > } >I have a module for openssh; the problem with this approach is that I wanted to keep that module as generic as possible so I can use it on other OS versions where this hack isn''t necessary. Do you have a suggestion for a more general workaround? -- Dan Urist durist@ucar.edu 303-497-2459 -- 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 Fri, Jan 28, 2011 at 11:22 AM, Dan Urist <durist@ucar.edu> wrote:> On Fri, 28 Jan 2011 11:13:18 -0800 > Nan Liu <nan@puppetlabs.com> wrote: > >> This does not appear to be a bug. There''s an implicit dependency for >> the file /etc/init/ssh.conf on file resource /etc/init. File /etc/init >> is in stage main, and File /etc/init/ssh.conf in in stage pre which >> cause a dependency loop. In this case, I would simply make the ssh >> package depend on the changes you''ve implemented. >> >> package { "ssh": >> ensure => latest, >> require => Class["disable_upstart_for_sshd"], >> } >> > > I have a module for openssh; the problem with this approach is that I > wanted to keep that module as generic as possible so I can use it on > other OS versions where this hack isn''t necessary. Do you have a > suggestion for a more general workaround?You can require disable_upstart class as a conditional by operating system and it should be part of your ssh module rather than a separate class. class ssh { case $operatingsystem { Ubuntu: { require ssh::disable_upstart } } ... } 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, 28 Jan 2011 11:40:38 -0800 Nan Liu <nan@puppetlabs.com> wrote:> You can require disable_upstart class as a conditional by operating > system and it should be part of your ssh module rather than a separate > class.If I understand correctly, you mean I shouldn''t use run stages at all. The problem with this approach is that I want to keep my openssh module as general as possible, so only do this behavior when running in a vserver. I guess I could try to use a custom fact for this, but I''d rather not have that logic in the openssh module (I have another module that handles configuration specific to vservers, so would prefer to keep it there). This seems like a reasonable use case for run stages. -- Dan Urist durist@ucar.edu 303-497-2459 -- 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.
jcbollinger
2011-Jan-31 16:57 UTC
[Puppet Users] Re: Run stage introduces dependency cycle
On Jan 28, 4:51 pm, Dan Urist <dur...@ucar.edu> wrote:> On Fri, 28 Jan 2011 11:40:38 -0800 > > Nan Liu <n...@puppetlabs.com> wrote: > > You can require disable_upstart class as a conditional by operating > > system and it should be part of your ssh module rather than a separate > > class. > > If I understand correctly, you mean I shouldn''t use run stages at all. > The problem with this approach is that I want to keep my openssh module > as general as possible, so only do this behavior when running in a > vserver. I guess I could try to use a custom fact for this, but I''d > rather not have that logic in the openssh module (I have another module > that handles configuration specific to vservers, so would prefer to > keep it there). This seems like a reasonable use case for run stages.The general rule appears to be that the resources in a given stage may require or listen to only resources assigned to the same or earlier stages. Therefore, if you are going to manager both /etc/init and / etc/init/ssh.conf then the latter must not appear in an earlier stage than the former. That seems logical to me. Therefore, given stage "pre" happening before stage "main", if you manage /etc/init/ssh.conf in stage "pre" then you must also manage /etc/init in stage "pre". 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.
Felix Frank
2011-Feb-01 11:00 UTC
Re: [Puppet Users] Run stage introduces dependency cycle
On 01/28/2011 11:51 PM, Dan Urist wrote:> On Fri, 28 Jan 2011 11:40:38 -0800 > Nan Liu <nan@puppetlabs.com> wrote: > >> You can require disable_upstart class as a conditional by operating >> system and it should be part of your ssh module rather than a separate >> class. > > If I understand correctly, you mean I shouldn''t use run stages at all. > The problem with this approach is that I want to keep my openssh module > as general as possible, so only do this behavior when running in a > vserver. I guess I could try to use a custom fact for this, but I''d > rather not have that logic in the openssh module (I have another module > that handles configuration specific to vservers, so would prefer to > keep it there). This seems like a reasonable use case for run stages.Take note of the $virtualization fact. IMO, generic modules *should* take advantage of standard facts like this one. HTH, Felix -- 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.