Michael DeHaan wrote:
> Dan Guernsey wrote:
>
>> Michael DeHaan wrote:
>>
>>
>>> Dan Guernsey wrote:
>>>
>>>
>>>
>>>> I am unable to test these at this time (I get an error from api.py
>>>> when it encounters:
>>>>
>>>> import acls
>>>>
>>>> What package/file does this come from?)
>>>>
>>>> Meanwhile, here are two patches. The first moves the builtins into
>>>> cheetah_macros and provides documentation. The second adds
>>>> cheetah_macros to setup.py and MANIFEST.in (you'll want to check my
>>>> work).
>>>>
>>>> I'll be as prompt as possible to help resolve any errors that this
>>>> untested code may (will) introduce.
>>>>
>>>> ~
>>>> Dan
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> cobbler mailing list
>>>> [email protected]
>>>> https://fedorahosted.org/mailman/listinfo/cobbler
>>>>
>>>>
>>>>
>>> Thanks!
>>>
>>> I tested this briefly with a doubly nested snippet and it looks good.
>>> I've additionally modified cobbler.spec so it can be packaged with the
>>> right permissions (and is marked "noreplace" so upgrades do not remove
>>> user changes).
>>>
>>>
>>>
>> OK, I'll remember that in any future patches
>>
>>
>>> I think the cheetah_macros file could still use considerable cleanup
>>> though this now it makes things much easier to edit.
>>>
>>> Points regarding the macro file:
>>> * Examples in things like "includeall" don't seem to be complete --
>>> perhaps have someone unfamiliar with what they do try to understand them?
>>>
>>>
>>>
>> I didn't mean to confuse anyone with all the wget and tar commands or
>> anything, but all it does is include all files in a given directory. The
>> result is basically the catenation of every file in the named directory.
>>
>>
>
> Sure, and it explodes them on the client? Basically a bit more text
> about the how would
> clear that up, I'd think. Others are welcome to help review too if they
> have comments.
>
Yeah, I'll include that with the Wiki (maybe this weekend)...
>
>>> * Lack of indentation. #raw... #endraw might help with this.
>>>
>>>
>>>
>> I wanted to avoid any unexplained indentation in the resulting kickstart
>> file. I must admit I didn't do much experimentation with the indentation
>> (as far as what ends up in the result), but if I remember right, it
>> would have required a lot of #slurp commands.
>>
>>
>>
>
> That's reasonable then.
>
>
>
>>> * Code for things like "set permissions" seems a bit weird (things like
>>> file[4] and repeated calls to chown, why not a loop?)
>>>
>>>
>>>
>> It does use a loop, (yes, the indentation -- rather lack of -- makes it
>> confusing, but a loop encompasses the entire function, the multiple
>> calls to chown represents the different ways of calling it (plain, 'p',
>> just calls chown. recursive, 'r', adds the -R flag. find, 'f', uses
>> 'find' to call chown recursively with restrictions.
>>
>
>
>
>
>> The 'file' tuple is
>> basically just a set of parameters. Each tuple in the list passed to
>> set_permissions with be translated into a chown and/or chmod command:
>> the first element of the tuple specifies which form (discussed above),
>> the next are the owner, group, and mode. Finally is the file or
>> directory name. In the case a find statement ('f' form) is used, an
>> additional element is used to specify a pattern.
>> Note that it will only call chmod if a mode is specified. Likewise,
>> chown is used if an owner is specified, and chgrp is used if a group is
>> specified. If both are specified, just chown is used (i.e. chown
>> owner:group file). This did end up being more complicated than I
>> intended, but it works.
>>
>> Maybe an example showing results will help:
>>
>> $set_permissions([
>> ('p', 'root', 'root', '600', 'my_file'),
>> ])
>>
>> yields:
>>
>> chown root:root my_file
>> chmod 600 my_file
>>
>> another:
>>
>> $set_permissions([
>> ('r', '', 'audio', '', '/usr/share/sounds'),
>> ])
>>
>> yields:
>>
>> chgrp -R audio /usr/share/sounds
>>
>> both with one call:
>>
>> $set_permissions([
>> ('p', 'root', 'root', '600', 'my_file'),
>> ('r', '', ''audio', '', '/usr/share/sounds'),
>> ])
>>
>> yields:
>>
>> chown root:root my_file
>> chmod 600 my_file
>> chgrp -R audio /usr/share/sounds
>>
>> This encourages a central location for setting file permissions. Even if
>> permissions are scattered among several snippets, we can keep the
>> chown/chgrp/chmod commands centralized in the result:
>>
>> among the snippets:
>>
>> $my_permissions.append(('p', 'root', 'root', '600', 'my_file'))
>>
>> later in the kickstart template:
>>
>> $set_permissions($my_permissions)
>>
>> also, because there is a predictable format for the list of tuples
>> (essentially a table), if the permissions are stored in a variable, they
>> can be checked for compliance by the server.
>>
>>
>
> Yeah, I understand the idea here, but it still seems a bit complicated
> to me, seeing just having a call to chown would make it available and be
> readily obvious to *nix admins. Perhaps we keep the macros file fairly
> minimalistic (perhaps containing only one or two simple examples) and
> then manage the more complex things (such as these macros) as part of
> the STIG templates if someone wants to use them? I believe it would be
> safe for a snippet to include another snippet with those defs.
>
> Some of the config munging is starting to get into things that would be
> better managed by something like augeas's augtool, though I suppose we
> can't assume it would be installed on all systems. It would definitely
> make a lot of the config munging easier.
>
I agree, it might be best to leave this to a config management tool. I
guess there's sort of a fine line when it comes to file permissions. Go
ahead and remove set_permissions, I'll later include it if/when I patch
in some STIG stuff.
>
>>> * Lacking examples for some of the copy file functions
>>>
>>>
>>>
>>>
>> The operation of the two copy file functions is so similar, that I
>> provided an example only for one. I assume the difference between
>> truncating and appending files is well-understood by most system admins.
>>
>>
>
> I find it's usually better to err on the side of too much documentation,
> as folks often have limited time or don't read things the same way.
> Saves trouble re-explaining things later over email and/or IRC.
>
Maybe this weekend...
>
>>> It might actually be easier to start a Wiki page for documentation on
>>> the macros feature and explain those there, where there's more room for
>>> elaboration.
>>>
>>>
>>>
>>>
>> I'll see what time I have to work on it. Perhaps there I should show the
>> resulting kickstart alongside my examples.
>>
>>
>
> That would probably be good... perhaps follow a common format for the
> comments for each one that always includes the example input and the
> example output.
>
>
>>> Anyhow, this is all applied in git devel now. Much appreciated!
>>>
>>> --Michael
>>>
>>>
>>>
>>> _______________________________________________
>>> cobbler mailing list
>>> [email protected]
>>> https://fedorahosted.org/mailman/listinfo/cobbler
>>>
>>>
>>>
>> Side note: do you have any suggestions for resolving the 'import acls'
>> issue I'm having?
>>
>>
>
> Should have been added into version control as of yesterday.
>
>
Cool,
> Anyway, I think we need to figure out if we want to maintain a library
> of "supported" macros here, or we just want to support the ability to
> include your own, and we include a few demos.
>
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.
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>
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.
> 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.
>> ~
>> 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
