... 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 cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler