Correct me if I'm wrong here, but doesn't the function in SystemInstaller do a lot of this? If you use the "mksimachine" command you can easily query or change which image is installed on which nodes. It also does all the underlying changes that need to happen to effect the update, and maintains a database of the system configuration.
It may not be 100% there, but its written and has been pretty heavily tested. One thing that we've discussed before is splitting the image building portion and the command line/front end portion of SystemInstaller and making the front end piece a required part of SIS and that would become the interface. Maybe its time to open that discussion up again? Mike On Mon, 2004-03-15 at 15:47, Brian Elliott Finley wrote: > Mark, > > This sounds really quite cool, and I appreciate your comments. I agree > that some of SystemImager has gotten unwieldy, and does not prevent a > user from getting bits of the system out of sync. I'm saving your > comments here, and will review them again when we get to the point of > implementing a solution. > > Thanks! > > -Brian > > > Thus spake Mark Seger ([EMAIL PROTECTED]): > >The thing that I've found very frustrating in learning how to use > >SystemImager is trying to figure out all the different steps one needs > >to do through to change which image is installed and where, especially > >because if you get one step wrong it does't work. To that end I built a > >tool that looks at file that contains entries something like this: > > > >#Config Net Abs/Rel BaseHost BaseAddr > >Mask Gateway > >mjsconfig eth0 S mjstest00.cag.com 192.168.250.40 > >255.255.255.0 - > > eth1 S - 16.21.17.40 > >255.255.248.0 16.21.16.253 > > > >This file contains mulitple names of configurations and describibe how > >to set up the network address ranges along with masks and gateways. In > >this case, the network addresses are created sequentally, and the host > >names always contain at least 2 trailing digits. > > > >This second file > > > >#MapName Script Name Nodes ConfigName Overrides > >mjstest mjsscript 6-8 mjsconfig > > > >says to take the setting in the first file for 'mjsconfig' and use them > >to install the image pointed to by the script 'mjsscript' using the > >overrides (if specified). they get layed down on nodes 6-8 which are > >described in a 3rd file that contains their mac addresses. > > > >I can then run a single script that uses this information to create a > >dhcpd.conf file, populate the overrides directory, create a set of > >softlinks for each hostname and point them to the master installation > >script, remove any files put in the /tptp directrly by netbootmond, > >create a new hosts file in the scritps directory as well as the images > >(by putting that too in the overrides directory) and do what's necessary > >to get ALL network addresses set up on each client. From the users > >perspective this is the only thing they have to run, once the tables > >have been populated. > > > >I guess my point in mentioning this is that ideally I'd like to see this > >kind of capability in SI, in which from the users persective they have a > >single command to run and not the many that are currently required. At > >the very least, if something new is going to happen to support multiple > >networks don't create yet another mkfoo that needs to be run along with > >all the others. > > > >-mark > > > >>Subject: Re: [Sisuite-users] Re: bug in systemconfigurator? > >>From: Brian Elliott Finley <[EMAIL PROTECTED]> > >>Reply-To: [EMAIL PROTECTED] > >> > >>Thus spake Sean Dague ([EMAIL PROTECTED]): > >> > >> > >>>On Tue, Feb 17, 2004 at 04:44:15PM -0600, Brian Elliott Finley wrote: > >>> > >>> > >>>>>Ultimately, putting everything in the SIS database seems best. > >>>>> > >>>>>I'd prefer adding this data in the autoinstallscript.conf file vs. a > >>>>>post-install script - we'd then be able to do it all in one call to SC, > >>>>>and without teaching users any new commands/hooks. > >>>>> > >>>>> > >>>>The only problem with that is that each machine needs a different entry, > >>>>which would require a different autoinstallscript.conf file for each > >>>>machine. Perhaps we could: > >>>>- include code in the autoinstall scripts that checks for the existence > >>>> of a file such as above "./scripts/interfaces-by-host" (or similar) > >>>>- if the file exists, use it to configure network interfaces > >>>>- if it doesn't exist, do one of the current methods of DHCP, STATIC, > >>>> REPLICANT > >>>> > >>>> > >>>Another solution to this problem is to lean on the SIS DB more, and make > >>>autoinstall scripts "per client" instead of "per image". > >>>mkautoinstallscript would then generate a script specific to the client. > >>> > >>> > >> > >>I think I like this idea. Anybody else have comments? > >> > >> > >> > >>>>Now that I mention that, perhaps it makes more sense to have another > >>>>--ip-assignment METHOD, where METHOD is TABLE or DB. > >>>> > >>>>TABLE would use a file such as above that lived in the scripts > >>>>directory. The benefit of this is it's text-editable. > >>>> > >>>>DB would use the SIS db. Benefit of this is canonical data. > >>>> > >>>>My only hesitation to using the DB for everything (in this case) is that > >>>>it's very handy to be able to simply edit a text file. But, perhaps we > >>>>could have a $tool that would: > >>>>- suck all the assignment entries out of the database, and pop them into > >>>> $EDITOR. > >>>>- user can view and edit to his hearts content > >>>>- when $EDITOR is closed, if there are changes, the $tool would confirm > >>>> with user, then update DB to reflect changes made to the file. > >>>> > >>>> > >>>Vi is not a user interface, and is very error prone for scripting. Doing > >>>any mass change of this data is better scripted through a commandline > >>>tool that will reject bad data with a reason to the user. > >>> > >>> > >> > >>This is actually what I'm proposing -- just that the data could be > >>prepared using $EDITOR instead of only with command line tools. In a > >>number of cases, including many DNS management systems I've worked with > >>(internal applications to deal with many zones and hosts, that is) I've > >>found it really useful to be able to use my favorite editor to make mass > >>changes, then to have my changes parsed and accepted or rejected, > >>allowing me to edit again. Oh yeah, "crontab -e" is another example. > >> > >> > >> > >>>Otherwise you end > >>>up with a lot more questions on the mailing list which come from subtle > >>>formating bugs. > >>> > >>> > >> > >>We definitely want to avoid this. > >> > >>So, in order to do the $EDITOR bit above, we certainly need to have the > >>command line tools (or at least their libraries) in place first. So > >>I think it's reasonable to make the $EDITOR bit a secondary goal, and > >>perhaps we'll decide it's not even necessary depending on how the > >>command line tools come out. > >> > >> > >> > >>>>Yes. I like that very much. All the data remains canonical, and in the > >>>>database, and our code only has to have one method for looking up such > >>>>info -> the DB. But users can still use a familiar interface (their > >>>>$EDITOR) to make changes. Although, this certainly needn't be the only > >>>>interface. > >>>> > >>>> > >>>> > >>>>>------------------------------------------------------- > >>>>>SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >>>>>Build and deploy apps & Web services for Linux with > >>>>>a free DVD software kit from IBM. Click Now! > >>>>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >>>>>_______________________________________________ > >>>>>Sisuite-users mailing list > >>>>>[EMAIL PROTECTED] > >>>>>https://lists.sourceforge.net/lists/listinfo/sisuite-users > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>--------------------------------------------------------- > >>>>Brian Elliott Finley Argonne, MCS Division > >>>>Phone: 630.631.6621 http://thefinleys.com > >>>>GPG: 3FF8 D096 0E0C D3F3 29B7 6518 D20B 1931 10F8 EE52 > >>>>--------------------------------------------------------- > >>>>Hi! I'm a .signature virus! Copy me into your signature to help me > >>>>spread! > >>>> > >>>> > >>>>------------------------------------------------------- > >>>>SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >>>>Build and deploy apps & Web services for Linux with > >>>>a free DVD software kit from IBM. Click Now! > >>>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >>>>_______________________________________________ > >>>>Sisuite-users mailing list > >>>>[EMAIL PROTECTED] > >>>>https://lists.sourceforge.net/lists/listinfo/sisuite-users > >>>> > >>>> > >>>-- > >>>__________________________________________________________________ > >>> > >>>Sean Dague Mid-Hudson Valley > >>>sean at dague dot net Linux Users Group > >>>http://dague.net http://mhvlug.org > >>> > >>>There is no silver bullet. Plus, werewolves make better neighbors > >>>than zombies, and they tend to keep the vampire population down. > >>>__________________________________________________________________ > >>> > >>> > >> > >> > >> > > > > > >------------------------------------------------------- > >SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >Build and deploy apps & Web services for Linux with > >a free DVD software kit from IBM. Click Now! > >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >_______________________________________________ > >Sisuite-users mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/sisuite-users > > -- Michael Chase-Salerno [EMAIL PROTECTED] IBM Linux Technology Center Poughkeepsie, NY Advanced Linux Response Team http://www.ibm.com/linux ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Sisuite-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-users
