... snip ...
> I figure the ones in cheetah_macros should be officially supported.
> Earlier you discussed having a separate RPM package for the STIG related
> stuff; this package could include several "officially supported" STIG
> macros that could be "activated" by putting:
>
> SNIPPET::STIG
>
> at the top of each kickstart that needs STIG features, or at the top of
> cheetah_macros to make them available to all kickstarts. Whether or not
> the RPM package modifies cheetah_macros automatically is your decision.
>
It's generally considered harmful for an RPM package to modify other
files owned by other RPMs in %post.
In those scenarios, that's when it's best to implement a conf.d
approach, though the SNIPPET::STIG solution
would be equally good.
> As far as support for the ability to include user-created macros, I
> figured users would just declare these in their own user-created
> snippets. If they wish to automatically include their macros, they can
> just SNIPPET them into cheetah_macros.
>
> Ooh, here's a great (read horrible) idea: We could keep an online
> database of useful community-generated snippets (similar, I guess, to
> the GNU autoconf archive). I suppose the User Wiki already does this,
> but it might be convenient for users to be able to download
> them.</distraction>
>
>
An easier route is probably to just create
/var/lib/cobbler/snippets/contrib/*, package them there
(with comments added to the top) and people can include them as
SNIPPET::contrib/foo
That saves the problem of writing a tool to make simple RPMs for them
and managing a yum repo.
I'm still not certain I want to do this however, as I think the primary
use case is for people simplifying what
they already have.
> The shipped cheetah_macros will provide examples of macros whether or
> not their "supported." I imagine user's may be fearful of modifying
> these to avoid breaking things, or to avoid modifying their setup so far
> from a "clean install" that they can't reasonably seek online help. Few
> users in the community will likely share a modified setup.
>
Anything in "/etc" needs to be supported as a core feature.
>> I used to know how to read perl -npe 's/^([ \t]*${param_name}[
>> \t]+)[\x21-\x7E]*([ \t]*(#.*)?)$/\${1}${sedesc($value)}, but it's not
>> something I want to encourage seeing more of.
>>
>> Snippets referencing augtool instead may really be worth exploring.
>>
>>
>>
> Sounds interesting, but I think that would consume more time that I have
> available. Nothing against you or this project, but I intend to become
> relatively detached after I add documentation to Wiki. I'll remain
> lurking about if anyone has questions you need me to answer, but I can't
> remain a permanent developer.
>
Didn't expect you to, though I will probably trim cheetah_macros down to
minimal on my own.
It is a very very nice feature in terms of having a place to put common
macro code, though
80 characters of Perl RE's is not sustainable long term.
I will probably contribute to it as I'd expect others to -- the feature
is goodness.
Meanwhile, the SNIPPET::STIG_common idea for defs seems to be a really
good idea, that way you
are not dependent on what ships in the macros file.
>>> ~
>>> Dan
>>>
>>> _______________________________________________
>>> cobbler mailing list
>>> [email protected]
>>> https://fedorahosted.org/mailman/listinfo/cobbler
>>>
>>>
>>>
>> _______________________________________________
>> cobbler mailing list
>> [email protected]
>> https://fedorahosted.org/mailman/listinfo/cobbler
>>
>>
>
> _______________________________________________
> cobbler mailing list
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
