On Wed, 2009-05-20 at 09:45 -0400, Rob McBroom wrote:
> On 2009-May-19, at 4:09 PM, David Lutterkort wrote:
>
> > Think of the subtree under /2 etc. as a record - in almost all cases,
> > these records have some notion of primary key;
>
> Which is why I wonder why /etc/inittab doesn't just use the 'id' field
> instead of assigning a number, or why /etc/hosts doesn't just use the
> IP address. But like I said, treating things as a numbered sequence is
> going to be unavoidable in some places, so my time is probably better
> spent figuring out how to handle it, rather than nitpicking this or
> that lens.
Heh ;) The reason to use numbered entries vs. the same label repeatedly
is a little subtle and has to do with how spacing is preserved when you
add or delete entries (with numbered entries, the spacing on hte line
'belongs' to the entry with that number, whereas with the same labels
the spacing of the lines is used in the order it appeared in the file,
even if a new entry is inserted in the middle)
> > If you always want your entry to show up after the 'si' line, you
> > ned to
> > do the explicit 'ins' as the first thing in your changes, something
> > like
> > 'ins 01 after */[id = 'si']'
>
> For the sake of discussion, let's say I was going to try an insert in
> a specific place. I haven't been able to get the path expression to
> work in that context. I have tried each of the following:
>
> "ins 0 after *[id='si']",
> "ins 0 after *[id=\"si\"]",
> "ins 0 after *[id=\'si\']",
> 'ins 0 after *[id="si"]',
> 'ins 0 after *[id=\'si\']',
> 'ins 0 after *[id=\"si\"]',
> "ins 0 after \"*[id='si']\"",
>
> And in every case, I get an error implying that it sees 'si' and the
> closing ] as two additional parameters, rather than as part of the
> expression.
>
> err: //was/Augeas[shutdown]: Failed to retrieve current state of
> resource: Error sending command 'ins 0 after *[id=' with params ["si",
> "]"]/Command 'ins 0 after *[id=' is not supported
Yeah, as Avi mentioned, you're being bitten by bug #2141 - if your git
is up to it, you could cherrypick the fix into your tree, otherwise
you'll have to wait for the next puppet release :(
> Should I file a bug or am I doing something wrong here? I'm running
> RHEL 5.3 with Puppet 0.24.8 and Augeas 0.5.0 from EPEL.
No need - Avi already did that ;)
> Sure, there's room for improvement, but I think this trick will
> accomplish what I want as long as I can count on changes being
> processed in order. For instance, canonical_maps doesn't exist by
> default, so in order to put a comment before it, I need to set it first.
>
> augeas { "main.cf":
> require => Package["postfix"],
> context => "/files/etc/postfix/main.cf",
> changes => [
> "set canonical_maps ldap:/etc/postfix/addresses.ldap",
> "ins #comment before canonical_maps",
> "set #comment[.=''] 'refer to LDAP for e-mail address'",
> ],
> notify => Service["postfix"],
> }
>
> Of course, the "#comment[.='']" expression throws errors too, so I
> can't use this until that's sorted out. :)
Yeah, #2141 at work again ;) One warning: since you are inserting a new
node, you'd need to guard this with an onlyif checking if canonical_maps
is there already - otherwise every puppet run will add a new comment
line.
David
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
