Hi,
I am trying to convince aptitude update to run only when a file
changes in /etc/apt/sources.list.d:
exec {
<snip>
"aptitude-update":
command => "/usr/bin/aptitude update",
subscribe => "$basedir/sources.list.d",
refreshonly => true;
}
File { owner => ''root'', group =>
''root'', mode => ''0644'' }
file {
"$basedir":
ensure => directory;
"$basedir/sources.list.d":
purge => true,
recurse => true,
ensure => directory;
<snip>
}
define apt::source ($deb_type, $url, $dist, $opt, $ensure) {
include apt
file {
"${apt::basedir}/sources.list.d/${name}.list":
content => "#$name\n$deb_type $url $dist $opt\n\n",
ensure => $ensure;
}
}
and then, from another module:
apt::source {
"Debian_backports":
deb_type => "deb",
url => "http://backports.debian.org/debian-backports",
dist => "squeeze-backports",
opt => "main",
ensure => present;
}
however, when I run this on a target system, puppet generates
the .list file in /etc/apt/sources.list.d but forgets to schedule a
run of aptitude update.
I tried some different approaches:
remove the subscribe line from the exec and add a notify =>
Exec[''aptitude-update'']; to the apt::source definition,
however, that
results to a depency loop to my surprise (the loop seems to be related
to the package ensure => latest objects, elsewhere...
so, what would be the best way to convince my puppet agents to run a
aptitude update when new files apear in the sources.list.d dir?
thanks for your help!
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.
On 12/01/2011 08:01 AM, Alexander Swen wrote:> Hi, > > I am trying to convince aptitude update to run only when a file > changes in /etc/apt/sources.list.d: > [...] > however, when I run this on a target system, puppet generates > the .list file in /etc/apt/sources.list.d but forgets to schedule a > run of aptitude update.It looks like you have at least two file resources: one for sources.list.d/, and one more for each file in it. Your exec is subscribed only to the sources.list.d/ resource. When you add more sources, that creates a new file resource, but it doesn''t "change" the directory as far as puppet is concerned, so it doesn''t trigger your exec. It seems odd, because obviously the directory *does* change, but as far as puppet is concerned, that resource that represents the directory wasn''t responsible for the change, so it doesn''t kick any subscribed resources. The solution is to get the file resources inside sources.list.d to kick the exec. Since you have potentially many such file resources but only one exec, probably this works best as a "notify => Exec[''aptitude update'']" in the file you declare inside apt::source. Once you solve that, the next problem you will encounter is that the update may or may not happen before you attempt to install the packages you want from backports. It took me a while to find a solution, so maybe you will find something like this useful: Exec[''aptitude-update''] -> Package <| |> Put that somewhere like inside your apt class, and no packages will be installed ever before running aptitude update. Of course that realizes virtual resources as a side effect, so if you are using virtual resources, maybe you need a different solution. -- 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 1 dec, 14:16, Phil Frost <ind...@bitglue.com> wrote:> Once you solve that, the next problem you will encounter is that the > update may or may not happen before you attempt to install the packages > you want from backports. It took me a while to find a solution, so maybe > you will find something like this useful: > > Exec[''aptitude-update''] -> Package <| |> > > Put that somewhere like inside your apt class, and no packages will be > installed ever before running aptitude update. Of course that realizes > virtual resources as a side effect, so if you are using virtual > resources, maybe you need a different solution.Hi Phil, thanks for your answer, I tried the first solution you suggest but it raises another problem: err: Could not apply complete catalog: Found dependency cycles in the following relationships: File[/etc/init.d/iptables] => Service[iptables], Exec[aptitude-update] => Service[iptables], Package[iptables] => Service[iptables] (an then some more of these "cycles".... This gets a lot worse once I add > Exec[''aptitude-update''] -> Package <| |>) below my iptables cfg (I can''t see the relation with apt, other than package): class iptables($internal_if=''bond0'') { package { "iptables": ensure => latest; } service { "iptables": require => [Package["iptables"],File[''/etc/init.d/iptables'']], hasstatus => true, enable => true, ensure => running; } exec { "/etc/iptables/cfg-firewall": subscribe => File["/etc/iptables/cfg-firewall"], refreshonly => true; } File { owner => ''root'', group => ''root'', mode => ''0644'' } file { "/etc/iptables": require => Package["iptables"], ensure => directory, mode => "775"; "/etc/init.d/iptables": mode => "755", source => "puppet://$puppetserver/iptables/iptables"; "/etc/iptables/cfg-firewall": require => File["/etc/init.d/iptables"], mode => "750", content => template("iptables/cfg-firewall.erb"); } } -- 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 Dec 1, 2011, at 8:41 AM, Alexander Swen wrote:> Hi Phil, thanks for your answer, I tried the first solution you > suggest but it raises another problem: > err: Could not apply complete catalog: Found dependency cycles in the > following relationships: File[/etc/init.d/iptables] => > Service[iptables], Exec[aptitude-update] => Service[iptables], > Package[iptables] => Service[iptables]Yeah, that''s annoying. It may help to throw "graph=true" in your puppet.conf, then look at the output in /var/lib/puppet/state/graphs (or set graphdir) with graphviz/dot or omnigraffle. Unfortunately, there''s no way to track down the source of a particular edge in the graph, so finding a solution might involve some hunting. -- 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.
> Yeah, that''s annoying. It may help to throw "graph=true" in your puppet.conf, then look at the output in /var/lib/puppet/state/graphs (or set graphdir) with graphviz/dot or omnigraffle. Unfortunately, there''s no way to track down the source of a particular edge in the graph, so finding a solution might involve some hunting.I am affraid I have to search to source of the cycle in the stages I created... (i think that the apt class should be run before some other classes but now some classes have a apt::source in them while they are in a later stage than the apt class) or something like that.... -- 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 Dec 1, 8:19 am, Alexander Swen <alex.s...@gmail.com> wrote:> > Yeah, that''s annoying. It may help to throw "graph=true" in your puppet.conf, then look at the output in /var/lib/puppet/state/graphs (or set graphdir) with graphviz/dot or omnigraffle. Unfortunately, there''s no way to track down the source of a particular edge in the graph, so finding a solution might involve some hunting. > > I am affraid I have to search to source of the cycle in the stages I > created... (i think that the apt class should be run before some other > classes but now some classes have a apt::source in them while they are > in a later stage than the apt class) > or something like that....Yes, stages can cause that kind of problem very easily. I think the best strategy when using stages is to make sure that no class has any explicit relationship to any class assigned to a different stage. All cross-stage relationships are either implicit already in the stage assignments or produce cycles, so you lose no expressiveness that way. Overall, however, I prefer to avoid stages altogether. 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.
> Yes, stages can cause that kind of problem very easily. I think the > best strategy when using stages is to make sure that no class has any > explicit relationship to any class assigned to a different stage. All > cross-stage relationships are either implicit already in the stage > assignments or produce cycles, so you lose no expressiveness that way. > > Overall, however, I prefer to avoid stages altogether. > > JohnHi John, I think you''re right on that, I will start removing all stages and put requirements in place to make sure that everything will be done in the right order. way better.. best 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.