On Mon, 10 Sep 2001, Mike Snitzer wrote:
> I assume that one can pick and choose which members of the anaconda
> kickstart class to modify and those that aren't redefined in the
> %installclass are left to utilize the original anaconda kickstart class
> routines?
As long as you inherit from the normal kickstart class, yes.
> I'm fairly comfortable with python; this is a very interesting way to add
> some nice features to our build process. It would be very cool if you
> could possibly give a quick little hello world example of how to make use
> of %installclass.
I wish I could -- I don't have access to test machines anymore to really do
this.
The basic idea is something like this:
---
<normal kickstart file>
%installclass
from kickstart import Kickstart
class CustomKickstart(Kickstart):
def __init__(self, file, isSerial):
return Kickstart.__init__(file, isSerial)
----
That should be pretty close to working. "file" is the original kickstart
file, which will not have been executed *at all*. The easiest thing to
do would be to open up "file" (a string variable), and use that as a template
for a new file (remove the %installclass though!!). Once you've written
the new file, just "return Kickstart.__init__("newfile", isSerial)", and
you should basically be go to go.
If you read the kickstart.py in the 7.1 anaconda package, you'll get a good
idea how this works. You can do anything in here; some hardware OEM's use
this mechanism to do different raid setups depending on the number of
drives in the system for example. Once you're in python, you're god. Of
course, the many consider the devil a god as well, so caveat emptor.
Erik
-------------------------------------------------------------------------------
| "Who is John Galt?" - Atlas Shrugged by Ayn Rand |
| |
| Linux Application Development -- http://people.redhat.com/johnsonm/lad |
