> -----Original Message----- > From: Sean Dague [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 11, 2003 10:38 AM > To: dann frazier > Cc: Brian Elliott Finley; Skouson, Gary B; Tenney, Nathan D; > [EMAIL PROTECTED] > Subject: Re: [Sisuite-devel] Re: Random SystemImager thoughts (Sorry > it's kind of long) > > > 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 > > > > * The database being a text based database. > > Although not text based for ease of implementation, the db is easily > accessed from perl.
But that means that it isn't going to be accessable from the client at install time since perl's not there. > > > > * 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 > > > > * The EXTRA_SCRIPTs idea -- being able to call > arbitrary scripts > > > from within the autoinstall script framework. > > 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: > > [USEREXIT\d+] > System Configurator supports an arbitrary number of user > exits. Each user exit will be run in turn. The user > exits are the last things run by systemconfigurator, so it > will have full access to the client operating system. The > first user exit to return a bad exit code will stop the > processing of the rest of the user exits. > > Each user exit block takes two stanzas. > > CMD The command to be run (e.g. touch). If the command is > not found, or not executable, this user exit will be > skipped. > > PARAMS > Any parameters needed to be passed to the command. > Future versions may allow the passing of other vari� > ables that System Configurator has access to, but this > is not yet supported. > I've seen the USEREXIT, and thought about using it, but with the SI scripts the way they are, it's easier to add it to the .master script as normal shell lines than as a USEREXIT. Also, If it's a USEREXIT, the script I run doesn't have access to the /tmp data from the install ramdisk. That's not a big problem though. > > > <snip> > > phase 1 could be having a config file for each clienttype, which > > contains all meta information - /etc/sis/clientdefs/<mastername>. > > mkautoinstallscript could use that information for > generating master scripts > > (which would definitely help upgrades). > > If you used the SIS db, and added other meta info a required, > you could use > existing infrastructure to do this. > > > phase 2 could be removing the symlinks, and having a config > file(s) that > > associates nodes with images. > > You would get this for free if mkautoinstallscript used the > SIS db to gather > its info about a client > > > 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". But you still need a new autoinstallscript for each node type because the node can't get this database information at install time. > > > 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 > > > 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. I still think it would be nice for the client to come up and have the install script know which disk partition information to use, which image to install and which network/boot/postinstall stuff to run. That works correctly now, except that we need a unique .master script for each node type. Because all of the scripting to "get things correct" at our site isn't in the default scripts generated by SystemImager, (adding alternate EFI boot partitions, getting short hostnames, dealing with multiple Ethernet interfaces like we want, etc.) I have modified the .master scripts. Now if I need to change things I have to modify all of the .master scripts. Ideally making the autoinstall script should just "do the right thing" would be best, but the logic begins to be quite complicated to put everything in the mkautoinstallscript program (or perl includes). I still think it would be best to make a "smart" .master script that could be used by any node. This script could determine configuration information or grab it from a database and proceed to execute the required "steps" by knowing the partitioning, fstab, image, network etc. ----- Gary Skouson ------------------------------------------------------- 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
