Dan Guernsey wrote: > The SNIPPET:: syntax should already be incorporated. In fact, it is no > longer limited to the top level kickstart anymore. For instance: > > ---------my_other_snippet----- > bar > ------------------------------------ > > -------my_snippet-------- > foo > SNIPPET::my_other_snippet > ------------------------------ > > -------my_kickstart-------- > SNIPPET::my_snippet > ---------------------------------
Great, I was skimming apparently. > > will work as expected. If they do not, please let me know. I'll move > the cheetah builtins to the cobbler.conf file. Let's call it something like /etc/cobbler/cheetah.includes, or something similiar so we can tell what it is. > Although I'll probably keep the SNIPPET one inside templateapi.py > because it's central to snippet functionality. Agreed! > I should finally be moved into my school apartment Tuesday, so > hopefully you'll see some more patches this week. Same deal with the > wiki: I'll see what I can put in there to help out. Great, much appreciated! --Michael > > ~ > Dan > > On Mon, Aug 4, 2008 at 2:30 PM, Michael DeHaan <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Dan Guernsey wrote: > > Sure: > > > > The kickstart file is a reasonable place to reconfigure some > security > > parameters on the system. The comment_lines and set_config_value > > function make this easy. Suppose we want to change the minimum > > password age to a month. > > > > If we want to keep record of the old value: > > $comment_lines('/etc/login.defs', 'PASS_MAX_DAYS') > > > > Then to change the actual value: > > $set_config_value('/etc/login.defs' ,'PASS_MAX_DAYS', '30') > > > > These will generate the proper perl/sed commands to change or > add the > > configuration value. > > > > Sometimes the kickstart file may need to modify scripts (typically > > bashrc or gdm Inits). The delete_command function can remove all > > instances of a bash command: > > > > $delete_command('/etc/gdm/Default/Init', 'exit[ \t]+0'). > > This was useful for appending content to the script and making > sure it > > gets executed. > > > > copy_over_file and copy_append_file read file content from the > server > > and inline it into the kickstart. The kickstart will then write this > > content to a destination file on the client, effectively copying a > > file from the server to the client. The append version appends > to the > > client file instead of replacing it. The copy_files method is a > > short-hand way of invoking the two file methods repeatedly: > > > > $copy_files([ > > ('w', 'etc/samba/smb.conf'), > > ('w', 'etc/audit.rules'), > > ]) > > > > This allows a user to keep a file tree (usually inside of the > snippets > > directory under a 'files' directory) that will be copied onto the > > clients. Additionally, the content of these files can be templated. > > For example: > > > > ---------etc/issue--------- > > SNIPPET::banner.txt > > ------------------------------- > > > > This particular example allows a consistent banner to be applied > > wherever one is needed. Also, the banner can be changed on a > > per-profile and per-system basis. > > > > Sometimes there are decisions that the kickstart file cannot > make for > > the deployer. In these cases, we need to make a list of things left > > for a human to do. The TODO function is a convenience function that > > adds readability and consistency to kickstart templates: > > > > At the top: > > #set global $todofile = '/root/kstodo' > > > > As needed: > > $TODO() > > Be sure to correct you audit log settings. > > EOF > > > > Using just: > > echo "Be sure to correct..." >> /root/kstodo > > can cause problems. What if > is used accidentally in place of >>? > > Also, it's easy to forget the filename. was it "ks-todo" or > "kstodo"? > > > > set_permissions works similarly in syntax to copy_files. It takes a > > list of tuples. This method was included to encourage users to keep > > all their permission settings in one area o the kickstart template: > > > > $set_permissions([ > > ('p', 'root', 'root', '700', '/root'), > > ('f', 'root', 'root', '600', '/root', '*'), > > ('r', 'root', 'root', '/etc/cron.*'), > > ]) > > The 'p' means, just the one file or directory. 'f' means recurse > over > > files only (it will descend into directories without changing the > > directories themselves. 'r' means recurse over files and > directories. > > The second, third, and fourth elements are owner, group, and mode, > > respectively. Pass an empty string '' to any of those to make no > > change. The fifth element is the file or directory to change. In the > > case an 'f' is used as the first element, a sixth element is used to > > further restrict affected filenames. > > > > The includeall method is a cheeseball function (I don't know if > should > > be in there), but it includes all files in a given directory > into the > > template. This allows one directory to contain several miscellaneous > > templates that can all be slurped into the kickstart. > > > > $includeall('misc') > > > > I hope that clears things up a bit. Remember, the copy_files method > > and the TODO method still seem broken on my end (for some reason, > > Cheetah is not substituting them at all). > > > > Anyway, enjoy! > > > > ~ > > Dan > > > > On Mon, Aug 4, 2008 at 9:44 AM, Michael DeHaan > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > > > > Dan Guernsey wrote: > > > Fixed some errors in the builtin methods. > > > > > > There are still some issues with $copy_files and $TODO. I will > > resolve > > > them later this week. > > > > > > ~ > > > Dan > > > > Dan, > > > > Thanks for the patches, I'll check it out and do some testing. > > Can you > > provide some examples of how someone might use each of these > functions > > and what they might do? > > > > --Michael > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > cobbler mailing list > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > https://fedorahosted.org/mailman/listinfo/cobbler > > > > _______________________________________________ > > cobbler mailing list > > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://fedorahosted.org/mailman/listinfo/cobbler > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > cobbler mailing list > > [email protected] > <mailto:[email protected]> > > https://fedorahosted.org/mailman/listinfo/cobbler > > > > This looks very good. I have only tested "SNIPPET" to make sure it > still works and it does. > > $SNIPPET('foo') ends up working as one would expect with the old-style > SNIPPET::foo > > The one patch we probably want to see made is the one that makes sure > that any old style SNIPPET::foo calls get replaced so that we can > eliminate the duplicate code there. > > The other thing I'd probably like to see is that we do move those defs > out to a file that users can easily add their own functions to. > Rather > than this being in site-packages, I think /etc/cobbler/cheetah.conf > would be appropriate. We could have templateapi.py read that file and > use contents from there. > > Otherwise, looks very good, and I can see users adding more useful > functions like this over time. We had one recent request to do > something more clever about how we model disk usage, and I can see it > being great for that. > > After this gets in, we'll have to see about including the STIG > securification snippets in stock cobbler too, likely > /var/lib/cobbler/snippets/stig so we can do things like: > > $SNIPPET('stig/foo') > > and so forth. > > Thanks! I've applied this and added you to the AUTHORS file. > Much > appreciated. > > If you'd like to maintain the docs or add more examples, you can do so > here: https://fedorahosted.org/cobbler/wiki/ExtendingCheetah though > ultimately I think having the examples as Cheetah comments ("##") > in the > /etc/cobbler/cheetah.conf is probably best. > > If you don't yet have a Fedora account, you'll need one to log > into the > Wiki. It's pretty simple at > https://admin.fedoraproject.org/accounts. > > Once again, thanks, and I'm looking forward to having all the > security/customization snippets as options in Cobbler as that is > certaintly easier than remembering a lot of arcane sed syntax. For > those interested to making patches to any of the above or adding more > functions (or more snippets to consider shipping with Cobbler or > just on > the Wiki), those are also always welcome! > > --Michael > _______________________________________________ > cobbler mailing list > [email protected] <mailto:[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
