On Tue, 2003-02-11 at 14:38, dann frazier wrote: > 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? It is stored using the Perl-MLDBM library. Its not directly human readable, but there are perl libraries provided by SystemInstaller to get to it, and the command line tools display the information as well
> can you point me to something that shows what all info is contained therein? > The SIS::DB man page describes the functions and we probably should list the attrs there, but they aren't right now. You can look at the module files which have an ATTR array right at the top. (a module is /usr/lib/systeminstaller/SIS/Client.pm) > > > > * 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. Actually what we're trying to do is get all the information in 1 place instead of scattered about in several different files. I know we aren't there yet, but creating more data stores will take us farther away rather than closer. > > > > > 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? > We don't store disk info in the database at all right now. So that is one place to improve things. We have a file that is used to build the autoinstallscript.conf, but it isn't retained. Its also a stopgap measure until we can come up with a nice way to get the disk info from the user. > > > 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. -- Michael Chase-Salerno <[EMAIL PROTECTED]> ------------------------------------------------------- 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
