Dan has a point that Perl is a bit of a beast to try and put in BOEL. However Perl is available in the image. I'm not sure if there is any info that is needed beyond the image name before we actually bring the image over, so it may be reasonable to have another method of getting that and then rely on the perl in the image for any additional info.
I also should point out that making any database remotely accessible is no small feat. It introduces all sorts of problems. A lot of these can be avoided by only giving read only access to the remote nodes, but it still becomes a larger project. If we were going down that route, we may want to consider using a "real" db like PostGreSQL. However, I don't think all the above is the right thing to do at this point. I think we can get a lot of benefit from the existing database just by expanding some of the data stored there and changing some of the tools to get info from there. Most obviously, mkautoinstallscript could get a lot of info from the DB and we could get to the point of having aiscripts on a per-client basis without changing much. I also think that having the aiscripts the way they are now is actually a good thing. It allows for flexibility and unique uses of SIS without requiring anyone to dig into SystemImager internals. It also makes working around any bugs or new problems much easier. In my opinion, the more work you can have the server in control of, the better. So, I think the first step down this road would be to change mkautoinstallscript to create scripts per client using info from the SIS db. We would additionally add the necessary attrs to the database to achieve this. Mike On Tue, 2003-02-11 at 23:34, Brian Elliott Finley wrote: > [snip] > > I really like the idea of the client pulling over the database (whatever > form) and accessing it directly. It offers a lot of flexibility. > > I also really like the idea of leveraging the SIS db which is already in > use. > > Finally, I really like Gary's examples of a shell script that can > retrieve data from a properly formatted text file. > > Therefore: > > * What if we were to include perl in the boel_binaries.tar.gz? > * What if the master database was based on the current SIS db, > and whenever it was updated, a small chunk of the data (just > enough to provide a client info on where to find the > appropriate boel_binaries.tar.gz) was written to a separate > file in a plain text db format (ala Gary's example)? > > 1. A booting client would retrieve the child db (and the master > db), and use a shell script to get it's info on where to find > it's boel_binaries tarball. > 2. Once it had perl from the boel_binaries tarball, it could > then access the master SIS db directly. > > -Brian -- Michael Chase-Salerno [EMAIL PROTECTED] IBM Linux Systems Technology Poughkeepsie, NY System Installation Suite www.sisuite.org ------------------------------------------------------- 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
