I am using the file_line type included in stdlib to add a line to /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then file_line resource adds the line back. It's happening on each run and I can't seem to figure out to get the sudo module's file resource to stop replacing the file on each run. I was hoping the file resource would ignore any lines propagated by the file_line resource. Is this a bug or am I just missing something?
On Sun, Jun 10, 2012 at 3:56 AM, Ryan Bowlby <rbowlb...@gmail.com> wrote:
> Hi All,
> I am using the file_line type included in stdlib to add a line to
> /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then
> file_line resource adds the line back. It's happening on each run and I
> can't seem to figure out to get the sudo module's file resource to stop
> replacing the file on each run. I was hoping the file resource would ignore
> any lines propagated by the file_line resource. Is this a bug or am I just
> missing something?
It's not a bug, it's just how things work.
What's happening is that you have two models (File_line and
File[/etc/sudoers]) of the same resource (/etc/sudoers) and the two
models conflict with each other.
The file resource has no knowledge of the file_line resource. I'd use
one or the other but not both.
A file resource is most appropriate when you can manage the entire
contents of the file. A file_line resource is appropriate when you
can't manage the entire contents of the file, only portions of it.
Thanks Jeff, I'll heed that advice. Wouldn't it make sense though to have the file resource "respect" changes made by file_line. Behind the scenes, if the file resource were able to know about the file_line additions and could remove them before calculating the md5 then both can be used on the same file. The current conflict doesn't have to be a conflict, I assumed puppet did this already.
On Sunday, June 10, 2012 9:58:23 AM UTC-7, Jeff McCune wrote:
> On Sun, Jun 10, 2012 at 3:56 AM, Ryan Bowlby <rbowlb...@gmail.com> wrote: > > Hi All,
> > I am using the file_line type included in stdlib to add a line to > > /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then > > file_line resource adds the line back. It's happening on each run and I > > can't seem to figure out to get the sudo module's file resource to stop > > replacing the file on each run. I was hoping the file resource would > ignore > > any lines propagated by the file_line resource. Is this a bug or am I > just > > missing something?
> It's not a bug, it's just how things work.
> What's happening is that you have two models (File_line and > File[/etc/sudoers]) of the same resource (/etc/sudoers) and the two > models conflict with each other.
> The file resource has no knowledge of the file_line resource. I'd use > one or the other but not both.
> A file resource is most appropriate when you can manage the entire > contents of the file. A file_line resource is appropriate when you > can't manage the entire contents of the file, only portions of it.
If you are fully managing the file use RI puppet-concat module instead of
file and file_line. I see it as
file: fully managed file or erb template.
file_line: partially managed file.
concat: fully managed file requiring per line resource injection.
Nan
On Jun 10, 2012, at 12:43, Ryan Bowlby <rbowlb...@gmail.com> wrote:
Thanks Jeff, I'll heed that advice. Wouldn't it make sense though to have
the file resource "respect" changes made by file_line. Behind the scenes,
if the file resource were able to know about the file_line additions and
could remove them before calculating the md5 then both can be used on the
same file. The current conflict doesn't have to be a conflict, I assumed
puppet did this already.
On Sunday, June 10, 2012 9:58:23 AM UTC-7, Jeff McCune wrote:
> On Sun, Jun 10, 2012 at 3:56 AM, Ryan Bowlby <rbowlb...@gmail.com> wrote:
> > Hi All,
> > I am using the file_line type included in stdlib to add a line to
> > /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then
> > file_line resource adds the line back. It's happening on each run and I
> > can't seem to figure out to get the sudo module's file resource to stop
> > replacing the file on each run. I was hoping the file resource would
> ignore
> > any lines propagated by the file_line resource. Is this a bug or am I
> just
> > missing something?
> It's not a bug, it's just how things work.
> What's happening is that you have two models (File_line and
> File[/etc/sudoers]) of the same resource (/etc/sudoers) and the two
> models conflict with each other.
> The file resource has no knowledge of the file_line resource. I'd use
> one or the other but not both.
> A file resource is most appropriate when you can manage the entire
> contents of the file. A file_line resource is appropriate when you
> can't manage the entire contents of the file, only portions of it.
> Hope this helps,
> -Jeff
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/NcyEJNStTq4J.
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 Sun, Jun 10, 2012 at 12:43 PM, Ryan Bowlby <rbowlb...@gmail.com> wrote:
> Thanks Jeff, I'll heed that advice. Wouldn't it make sense though to have
> the file resource "respect" changes made by file_line. Behind the scenes, if
> the file resource were able to know about the file_line additions and could
> remove them before calculating the md5 then both can be used on the same
> file. The current conflict doesn't have to be a conflict, I assumed puppet
> did this already.
It totally makes sense, it's just a bit difficult to implement. At
least the implementations I'm imagining are. Surely there's a simple
solution, I'm just not seeing it right now.
We only recently built the next generation of our persistent storage
system, but I'm not sure it's ready to store things like partial
resource attributes. I'll ask them tomorrow.
On Sun, Jun 10, 2012 at 1:04 PM, Nan Liu <n...@puppetlabs.com> wrote:
> If you are fully managing the file use RI puppet-concat module instead of
> file and file_line. I see it as
> file: fully managed file or erb template.
> file_line: partially managed file.
> concat: fully managed file requiring per line resource injection.
Yes, the concat module [1] is pretty awesome. I've been working with
it in the dhcp module recently and it works really well.
Depending on your sudo version you could also put snippets in
/etc/sudoers.d. This has the advantage of allowing each class to manage its
own sudoers file without any Puppet conflicts.
On Jun 10, 2012 3:56 AM, "Ryan Bowlby" <rbowlb...@gmail.com> wrote:
> I am using the file_line type included in stdlib to add a line to
> /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then
> file_line resource adds the line back. It's happening on each run and I
> can't seem to figure out to get the sudo module's file resource to stop
> replacing the file on each run. I was hoping the file resource would ignore
> any lines propagated by the file_line resource. Is this a bug or am I just
> missing something?
> -Ryan
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/L7OtmlWKio0J.
> 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.
> Depending on your sudo version you could also put snippets in > /etc/sudoers.d. This has the advantage of allowing each class to manage its > own sudoers file without any Puppet conflicts.
Make sure to implement some kind of ordering for the snippets. From the man-page: "Where there are multiple matches, the last match is used (which is not necessarily the most specific match)". This has bitten me more than once.
