Thus spake Michael Chase-Salerno ([EMAIL PROTECTED]): > 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.
I think considering a "real" db is a reasonable thing. Small C client in BOEL that directly queries the DB. Another possibility is requiring a web server on the imageserver, and having the client use cgi to pull it's data. It currently has a command line web client, and we could do command line queries via CGI. Either of these opens up additional information to the outside world, for non-ssh users. Even the web service could be secure for ssh users as port forwarding is used to make connections to the server -- it can be completely firewalled except for port 22. > 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. BTW, I kinda like the term "ai-scripts". Maybe we'll switch to using that. ;-) > 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 > -- --------------------------------------------------- Brian Elliott Finley http://baldguysoftware.com/ phone: 630.803.8183 http://systemimager.org/ --------------------------------------------------- ------------------------------------------------------- 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
