The file brian describes below is very similar to what I have done. I'm guessing there would be tools that are part of SystemImager to help one build such a table, preferably an extention to mkdhcpserver because all this needs to tie together and mulitple steps increase the probability of forgetting something. Since I always deal with mulitple interfaces, I don't use mkdhcpserver but rather use a tool I wrote that both populates dhcpd.conf as well as generates my interface assignments. We can talk about that more if there is any interest...
I guess I don't know what the SIS database is. Is this part of SystemImager? Does it get downloaded to each machine? The way I could imagine it working, and I don't have a strong enough feeling for the 'philosophy being the SI tools to know what is the best way, is one of the following:
- when the autoinstall script gets generated, it could have a section that looks something like the following, which I actually hacked and made work. The trick here is to assign values to IPADDR1..n and associated variables once the script begins execution on the target machine.
[NETWORK] HOSTNAME = $HOSTNAME DOMAINNAME = $DOMAINNAME
[INTERFACE0] DEVICE = eth0 TYPE = static IPADDR = $IPADDR NETMASK = $NETMASK
[INTERFACE1] DEVICE = eth1 TYPE = static IPADDR = $IPADDR1 NETMASK = $NETMASK1 EOL
in addition at script gereration time one could build an earlier section that looks like the following to assign those values, which is what I did. the only downside for doing this is that the script has hardcoded network addresses AND can be pretty big for very large sites. It would have to be regenerated every time network assignments need to change, not necessarily all that bad, but something else to deal with.
if [ "$HOSTNAME" = "mjstest7" ]; then IPADDR1="16.21.17.47" NETMASK1="255.255.248.0" fi if [ "$HOSTNAME" = "mjstest8" ]; then IPADDR1="16.21.17.48" NETMASK1="255.255.248.0" fi
- alternatively, and this what I currently do without any code changes to an SI code is simply run a perl script after the system boots that reads the table, generates the addresses and does a 'service network restart'.
-mark
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
