On Wed, 2003-02-12 at 19:19, Skouson, Gary B wrote: <snip>
> > The problem I'm seeing here is there is an attempt to try to > > create ways > > arround the SIS infrastructure for edge cases, instead of > > saying that those > > are real requirements, and how do we build and interface to > > support them, > > and an engine to implement them. > > That sounds great, but I haven't had a lot of success in having the > auto-generated .master script get me the image I need. The scripts get > me a system that's close, but I always seem to need to edit something to > get something set up like I need. Unfortunately the changes I need to > make need to be made to each of the .master scripts. That's usually > only a handful, but it's a pain, especially when I miss one. I'd be curious to learn more about the changes you need to make, perhaps they are generally useful and can be folded into the base. I believe that changing the aiscripts to be more abstract would have made it much more difficult for you to make your changes. Since the script is now very straight forward and totally controlled on the server, any changes you make there WILL happen on the client in the way you code, for better or worse. We shouldn't lose this. > I could code these changes into the normal generation code, but it seems > that in continuing to add special cases to the script generation code > Ill eventually end up with more command line options than gcc. > > So, I was thinking about ways to modularize the .master script. Mostly > the install script for a node does: > partition the disk > mount the filesystems > put the OS on > do some override stuff > add the /etc/fstab > run systemconfigurator > let the server know we're done > unmount things > reboot/wait etc. Modularization is a good thing, what you've outlined here is basically what the scripts do today. So other than some structural benefits, modularization wouldn't really change the basic function. > With some kind of simple database, it seems like it would be easy for a > generic .master file to determine if nodeA needs partition scheme a,b,c > or d. If the image we want to install is 1,2 or 3, what overrides to > apply etc. It would also give a way to add another step in there > somewhere to do some extra "site specific" stuff. > But again, this makes it less obvious what is happening and harder for a hacker to modify it. > Maybe I'm just one of those "edge cases". I'm fine with that. I agree > that it's impossible to support every edge case and you're better off > looking at what's in the best interest of the most users. I've been > working around things so far, and we'll eventually do something here at > our site that works for us. Mostly I'm interested on how the future SI > stuff is planning to deal with things. If there's something in the > works that I can use and extend to fill my needs, I'd rather do that > than go off and do something that'll never work on a future SI version. > > It's been great to see the concerns and ideas that others have had. > > ----- > Gary Skouson > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sisuite-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/sisuite-devel -- Michael Chase-Salerno <[EMAIL PROTECTED]> ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
