There's no need to allow the ownership/permissions of a fragment to be set as
the concat define sets ownership/permissions on the final aggregated file.
Revert validation of the target param as an absolute path and allow it to be an
arbitrary string. This is so the
concat { <foo>: path => ... }
concat::fragment { ...: target => <foo> }
association may be symbolic as long as concat path param is specified. This
should resolve the symbolic name regression introduced in:
https://github.com/puppetlabs/puppetlabs-concat/commit/eaf84079
The hard coded path of `/usr/local/bin/concatfragments.sh` hasn't been
used for "a long time" so there's no reason to carry the cleanup around
any longer.
The use of $::id to set the default user/owner and group has caused
multiple bugs in the past, is incorrectly used to infer the egid,
introduces a dependency on the `id` fact, and provides no functionally
that can't be accomplished by passing `undef` or not setting the
respective params on the file & exec types.
A possible alternative would be to introduce a dep on the $::gid fact
but that would mean the entire module would depend on a version of
facter than hasn't shipped yet (unworkable) or to add a gid/egid fact
into this module (ugly).
Unless the class `concat::setup` has been manually included into the
manifest before using the `concat` / `concat::fragment` defined types,
the puppet master will generate this warning while compiling the catalog.
Tue Oct 15 14:05:06 -0700 2013 Scope(Concat[/etc/exports]) (warning):
Could not look up qualified variable 'concat::setup::root_group'; class
concat::setup has not been evaluated
The need to `include concat::setup` directly into the manifest has never
been part of the documented API.
