Hi Sean, thanks for the reply. Let me try to explain a bit how I'd like to use sis_reload.
In a cluster we generate a per image autoinstallscript which contains lines like the following: cat <<'EOF' > /a/etc/fstab /dev/hda6 / ext3 defaults 1 2 /dev/hda5 swap swap defaults 0 0 /dev/hda1 /boot ext3 defaults 1 2 /dev/fd0 /mnt/floppy auto noauto,owner 0 0 none /dev/pts devpts defaults 0 0 none /proc proc defaults 0 0 nfs_oscar:/home /home nfs rw 0 0 EOF I'd like to replace the whole section by the line: chroot /a/ sis_reload fstab For the network setup we have: chroot /a/ systemconfigurator --excludesto=/etc/systemimager/systemconfig.local.exclude --configsi --stdin << EOL || shellout [NETWORK] HOSTNAME = $HOSTNAME DOMAINNAME = $DOMAINNAME GATEWAY = $GATEWAY [INTERFACE0] DEVICE = eth0 TYPE = static IPADDR = $IPADDR NETMASK = $NETMASK EOL I'd like to replace this by the line: chroot /a/ sis_reload network The advantages are obvious: 1. No need to regenerate autoinstall script when fstab changed (e.g. added a new nfs mount). Exception: if partitioning changed. 2. No need to regenerate autoinstall script when the network setup is changed (added an interface or changed the IPs). 3. The autoinstall script configures ALL interfaces defined in the SIS database right from the start. This is otherwise difficult, except one uses per host autoinstall-scripts or some dynamic computation of an $IPADDR2 out of $IPADDR. 4. sis_reload can be used also when the cluster is up and running for doing reconfigurations without the need to reinstall. sis_reload is meant as an admin tool for already installed clusters which synchronizes some SIS db parameters with the cluster nodes. It can evolve to become smarter, right now it's only a quick hack which happens to be also useful at install time. On Wednesday 30 March 2005 20:36, Sean Dague wrote: > > I'm not sure whether you argue against sis_reload or not. The SI > > release I can access and download is version 1.04 and that one has > > huge deficits when it comes to multiple interfaces. I was trying to > > solve that problem by using the SIS infrastructure and database, as > > well as systemconfigurator for loading the changes into the > > clients. The SIS infrastructure is prepared for multiple interfaces, > > but I needed something like sisqd/sisqc to access it from the client > > nodes. If there is another way, please explain it. > > I'm not sure that sis_reload is the right approach. ÂMy personal feeling is > that this information should come from the SIS db and be incorporated into > the autoinstall scripts directly by systemimager. Actually I prepared sisqd to generate the data with the help of a systeminstaller owned module (the same which generates the autoinstallscript data). I don't remember exactly why it didn't work and I decided to simply copy and edit the corresponding code. I can have another look and try to debug the problem. By the way, the SIS dabase is itself quite scattered. Soem data is in the database, some is in XML files in the image. Any plans to "unify" this? > ÂRight now there are too > many instances of having to go around the autoinstall scripts to get things > done, when it is clearly what should own/drive the install process. ÂPut it > in the main path, then it will tend to be more maintained. Sounds encouraging. I will try to debug the issue mentioned above and use only si-owned modules for generating the fstab and network input file. If that's done, I'd be happy to add this to sis main path, if I get the permission (AKA cvs write access). Thanks, best regards, Erich ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
