Proper Augeas usage
Tim Stoop
I'm trying to work with augeas to add pinnings to my /etc/apt/
preferences file. But I'm not getting my head around it. If I do the
simplest I can think of:
augeas { "Apt/preferences pinnings for augeas-lenses.":
context => "/files/etc/apt/preferences",
changes => ["set 00/Explanation 'We need these from backports.'",
"set 00/Package augeas-lenses",
"set 00/Pin release",
"set 00/Pin/a lenny-backports",
"set 00/Pin-Priority 999"],
}
it adds the definition to the bottom of the file each time. If I
change the context into
context => "match /files/etc/apt/preferences/*/Package augeas-
lenses",
it only works if there's already an augeas-lenses definition
available. In which "working" is a large word, because if the current
Pin-Priority is 900, it doesn't set it to 999. If there's no augeas-
lenses definition available, it *segfaults*:
/usr/lib/ruby/1.8/augeas.rb:48: [BUG] Segmentation fault
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
Aborted
So I'm at a bit of a loss. What am I doing wrong and how should I be
handling these kind of situations?
For reference, I'm using augeas stuff from lenny-backports:
augeas-lenses 0.7.0-1~bpo50+1
augeas-tools 0.7.0-1~bpo50+1
libaugeas-ruby1.8 0.3.0-1~bpo50+1
libaugeas0 0.7.0-1~bpo50+1
--
Kind regards,
Tim
David Lutterkort
> Hi all,
>
> I'm trying to work with augeas to add pinnings to my /etc/apt/
> preferences file. But I'm not getting my head around it. If I do the
> simplest I can think of:
>
> augeas { "Apt/preferences pinnings for augeas-lenses.":
> context => "/files/etc/apt/preferences",
> changes => ["set 00/Explanation 'We need these from backports.'",
> "set 00/Package augeas-lenses",
> "set 00/Pin release",
> "set 00/Pin/a lenny-backports",
> "set 00/Pin-Priority 999"],
> }
>
> it adds the definition to the bottom of the file each time. If I
> change the context into
>
> context => "match /files/etc/apt/preferences/*/Package augeas-
> lenses",
You want to restrict when to make those changes with the onlyif
paramater, something like
augeas { "...":
context => ...
changes => ...
onlyif => "match *[ Pin = 'release' and Package = 'augeas-lenses'] size == 0"
}
> it only works if there's already an augeas-lenses definition
> available. In which "working" is a large word, because if the current
> Pin-Priority is 900, it doesn't set it to 999.
You'd need to add another augeas resource to cover that case, something
like
augeas { "...":
context => "/files/etc/apt/preferences[Pin = 'release' and Package = 'augeas-lenses']",
changes => "set Pin-Priority 900",
onlyif => "match * size == 0"
}
> If there's no augeas-
> lenses definition available, it *segfaults*:
>
> /usr/lib/ruby/1.8/augeas.rb:48: [BUG] Segmentation fault
> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>
> Aborted
When that happens, is libaugeas0 installed ?
David
Tim Stoop
Thanks for your reply, it cleared up some things!
On 22 feb, 20:35, David Lutterkort <lut...@redhat.com> wrote:
> You want to restrict when to make those changes with the onlyif
> paramater, something like
>
> augeas { "...":
> context => ...
> changes => ...
> onlyif => "match *[ Pin = 'release' and Package = 'augeas-lenses'] size == 0"
> }
Ah, so I was wrong in thinking that augeas would treat these kind of
config blocks as one entity with different variables. That makes the
augeas type a little less useful than I thought, but I probably
should've figured that out when I was building the lenses I needed.
There's simply no $name equivalent in augeas. Thanks for making that
clear.
> You'd need to add another augeas resource to cover that case, something
> like
>
> augeas { "...":
> context => "/files/etc/apt/preferences[Pin = 'release' and Package = 'augeas-lenses']",
> changes => "set Pin-Priority 900",
> onlyif => "match * size == 0"
> }
Ok, so I'd be better off creating a type that adds these different
kinds of augeas resources with different checks for each variable part
of the resource.
> > If there's no augeas-
> > lenses definition available, it *segfaults*:
>
> > /usr/lib/ruby/1.8/augeas.rb:48: [BUG] Segmentation fault
> > ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>
> > Aborted
>
> When that happens, is libaugeas0 installed ?
Yes, very sure it is, because my augeas resource depends on
Package["libaugeas-ruby1.8"], which depends on libaugeas0.
Thanks for the tips! I'll see what I can make of it. Even though it
requires more code, I still think augeas is a cleaner solution than
concatenated files (although I love your concatenated_file module,
DavidS!).
--
Kind regards,
Tim
David Lutterkort
> On 22 feb, 20:35, David Lutterkort <lut...@redhat.com> wrote:
> > You want to restrict when to make those changes with the onlyif
> > paramater, something like
> >
> > augeas { "...":
> > context => ...
> > changes => ...
> > onlyif => "match *[ Pin = 'release' and Package = 'augeas-lenses'] size == 0"
> > }
>
> Ah, so I was wrong in thinking that augeas would treat these kind of
> config blocks as one entity with different variables. That makes the
> augeas type a little less useful than I thought, but I probably
> should've figured that out when I was building the lenses I needed.
> There's simply no $name equivalent in augeas. Thanks for making that
> clear.
The problem is that there's no good primary key for these changes. From
looking at your troubles, it seems that it might be much more usable if
the augeas type operated more on the level of 'I am going to change a
certain part of the tree to look exactly like this'. To pick the part of
the tree, you'd specify a path expression, for example
'/files/etc/hosts/*[ipaddr="127.0.0.1"]', and also a path that can be
used when the entire entry is missing, say '/files/etc/hosts/01'.
Writing down what you want that subtree to look like will also be
interesting. Puppet doesn't have data structures to do that, so you'd
have to encode them in a string, e.g. using the tree notation that
Augeas itself uses.
With that, we'd have a type that looks more like this:
augtree { "etc-hosts-localhost":
find => "/files/etc/hosts/*[ipaddr = '127.0.0.1']",
create => "/files/etc/hosts/01",
tree => " { ipaddr = 127.0.0.1 } { canonical = localhost } { alias = local.local } "
}
The above would make sure that your entry for localhost looks a certain
way, and would not require any gymnastics with onlyif to become
idempotent. Similarly, to make sure that localhost has an alias of
'host.example.com', you would write
augtree { "etc-hosts-localhost-alias":
find => "/files/etc/hosts/*[ipaddr = '127.0.0.1']/alias[ . = 'host.example.com']",
value => "host.example.com"
}
With that, it would be reasonable to not allow two augtree resources
with the same find parameter.
Of course, there's the small issue of implementing a type like the
above. The full docs would look something like
augtree {
find => "..." # Path expression matching the subtree to work on; mandatory
create => "..." # Path expression to use when find doesn't match at all; optional, use value of 'find' by default
tree => "..." # The tree that should be there underneath 'find'
value => "..." # The string value to assign to the tree node 'find'
}
David