Thus spake Dann Frazier ([EMAIL PROTECTED]): > On Sat, Feb 14, 2004 at 10:52:42PM -0600, Brian Elliott Finley wrote: > > This is actually one of the big questions on my plate right now. Some > > ideas (in no particular order): > > > > - SI post-script that reads a text file (stored in the ./scripts > > directory) and invokes System Configurator for each interface > > specified. Such a text file might look something like: > > > > #<HOST> <IFACE> <IP> <MASK> <BCAST> <GATEWAY> > > host1 eth0 192.1.1.1 255.255.255.0 - - > > host1 eth1 192.2.2.1 255.255.255.0 - - > > host1 tr1 192.3.3.1 255.255.255.0 - - > > host1 eth0:1 192.4.4.1 255.255.255.0 192.4.4.255 192.4.4.254 > > > > - Maybe incorporate this info into the SystemInstaller database somehow. > > Perhaps store it there, but generate this file from it? Dunno. Maybe > > even have the client query the database directly over the net? Dunno. > > 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 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. 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
