On Tue, Feb 11, 2003 at 01:38:03PM -0500, Sean Dague wrote: > On Tue, Feb 11, 2003 at 11:05:48AM -0700, dann frazier wrote: > > On Mon, Feb 10, 2003 at 11:25:35PM -0600, Brian Elliott Finley wrote: > <snip> > > > Specifically, I like: > > > * The idea of having a database for tracking client information > > > -- this ties in nicely to some design ideas that are currently > > > on the table. > > This exists in SIS today via SystemInstaller
k. > > > * The database being a text based database. > > Although not text based for ease of implementation, the db is easily > accessed from perl. what format is it in? can you point me to something that shows what all info is contained therein? > > > * Breaking up the autoinstall scripts into components, and > > > having clients pull the pieces they need. > > > * The idea of eliminating the symlink "database". > > With the mapping in the SIS database, per client autoinstall scripts as the > default would be the best approach that means more places for redundant information, and lots of extra files. imo, a file that lists the clients assigned to an image, or something similar, is easier to maintain. > > This was added to SystemConfigurator with the 2.0.0 release (Oct/Nov '02). > The functionality is call USEREXIT. The excerpt from the SC man page is > included for reference: this works for post install stuff, not for pre-install stuff (like making the client smart enough to choose an image based on its hardware config). > > phase 3 could be adding /etc/sis/partitionschemes/, and referencing them > > from within /etc/sis/clientdefs/<mastername>. > > Adding DISK info to the SIS db has been a goal for a while. Mike C-S has a > more info about the designs we kicked arround. Again, if > mkautoinstallscript talked to the SIS db, it would "just work". well, for some value of "just work". i realize that SIn must be storing this info in some format, but how how well does that match up w/ what's in autoinstallscript.conf, content wise? i'm guessing it must have at least the same content? and what is the state of the frontend tools for manipulating this dbase? is it easy to s/reiserfs/xfs - /dev/hda -> /dev/cciss/disc0, etc? > > phase 4 could be adding a PRE_INSTALL / POST_INSTALL options to the clientdefs > > configs, to enable adding arbitrary scripts, and having a defined environment > > for those scripts (you can find your IP in the IPADDR variable, etc). > > You can do this today via USEREXITS not the pre install stuff. > > phase 5 could be breaking up the master script and eliminating its need > > to exist (and therefore the need to be regenerating), by making the install > > client smart enough to grabbing the appropriate pieces it needs at runtime. > > You would have to add a lot more logic on run time to the client. I would > state this is a bad idea because the fact that BOEL is pretty dumb, and the > scripts it runs are smart (and static). This is great benefit as there are > a small number of moving parts on the client, and anything that goes funky > can usually be corrected by vi on the server. If the code was in the > client, you'd have to rebuild BOEL for a fix, which would suck much more. the code doesn't necessarily have to reside in boel - a smart (but not hard coded) master script could do this work too. -- --------------------------- dann frazier Hewlett-Packard Linux Systems Division [EMAIL PROTECTED] (970) 898-0800 ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
