OK, I understand, in your case is simpler to have an image for each hw platform. Remember that if you have to setup a lot of network cards you can write post-install scripts depending on informations that can be found in /etc/hosts (I usually do this). And to handle different partitioning schemas without having to replicate the whole image you can use --config-file and --script options with si_mkautoinstallscript. Simply create different autoinstallscript.conf (one for each platform) and build a master script for each schema. Then you can play with links in /var/lib/systemimager/scripts/ to properly select the master script to image the clients, but all will use the same image data...
Anyway if packages change or other complicated stuff in this case it's alyway better to create different images, even if this means to replicate a lot of data... Regards, -Andrea Jason Knudsen wrote: > I'll check out rdiff-backup and see what it can do! > > Our environment is a bit more different from platform to platform than > just the disk type.. Such as based on the different hardware, we produce > different sized swap files based on the system memory... each system has > different NIC cards that when seen with RH40 always seem to be different > per platform , eth0 or eth2 or even eth1 sometimes. (and each system has > 7 NICs in general) > > So there are plenty of differences and I don't think SystemImager can > really cater to all of that.. I thought of creating a masterfile and > inputting all these settings as variables and then based on the hardware > type it'll grab all the different variables out of the database and > inputting them dynamically. > > Andrea Righi wrote: >> Anyway, it should be possible to use the same image also if you have >> clients with different hardware. What can change is: >> >> - disks type (SCSI, IDE, SATA, etc): you can resolve with option >> --autodetect-disks in si_mkautoinstallscript >> >> - kernel modules, initrd and boot-loader: systemconfigurator should do >> this job >> >> - other issues: write a custom post-install script >> >> I mean theoretically it shouldn't be necessary to spend disk space to >> replicate images only for hardware differences, but only if you have >> logical differences (e.g. front-end nodes, back-end nodes, I/O nodes, >> etc). >> >> Apart all it should be very interesting to have a mechanism to save only >> the differences between an image and a golden client into an override. >> Surely it's an interesting feature and I'll investigate on that. Maybe a >> tool to implement this could be rdiff-backup >> (http://www.nongnu.org/rdiff-backup/), but I'd like to have it >> automatically included in systemimager, in particular to have an option >> in si_getimage.... >> >> Regards, >> -Andrea >> >> Jason Knudsen wrote: >> >>> I just wanted to share my experience with SystemImager.. I may be doing >>> something different than most of you and wanted to enlighten you to this >>> technique I've sort-of established... >>> >>> Essentially what I've been attempting to do in our data center was to >>> utilize SI in a proof-of-concept approach to see what I could do with it >>> and if it were something better to replace our current method which is >>> quite hacked up and uses pxeboot and kickstart et al. >>> >>> I wanted to use SystemImager because of it's great amount of >>> functionality - Quick deployment of images, using bittorrent, rsync, >>> flamethrower.. Monitoring.. Virtual Console.. among it's vast amount of >>> tools to easily manage imaging and prepare the whole boot environment or >>> just for the fact that it can be used with CDs, Floppys.. USB keys.. >>> etc... I don't need to explain about how great and useful this product >>> truly is! >>> >>> But my problem? A lot of different hardware platforms needed to be >>> supported and I don't like the idea of using and maintaining several >>> images for our development environment. The administration would become >>> a headache to say the least. So what I've been attempting to do is >>> establish a SINGLE Golden Image and use this across our different >>> hardware platforms... I've been making my tests with RHEL4.0. >>> >>> My technique was such that I collected a Golden Image of each hardware >>> platform with RH4.0 installed and then did a diff against my true Golden >>> Image to see which files have changed. Those files I've then extracted >>> from each hardware platform and placed them into their respective >>> OVERRIDE directories. Then based on which platform used, it called a >>> different master file which dictated such things are which network card >>> to use and so on, so forth.. but ultimately each master file dictated >>> which OVERRIDE directory to use. This has ensured that I have an easy >>> method to implement new hardware platforms and reduced my administration >>> / disk space requirements dramatically. Once I was sure that it was >>> capable of installing on said hardware platform, I would then remove >>> it's corresponding golden image to save space. It had served it's >>> purpose (diff.) >>> >>> To tie all this together I built my own script that requires 2 inputs.. >>> 1) OS type and 2) hostname. Based on this information it would reach out >>> to a database (our asset database) to grab information of that hostname >>> (hardware type... etc..) and based on this input I could automatically >>> determine which master file to use which would then setup all of the >>> proper stuff! Presto.. one command and we've got total automation. >>> >>> I've only spent time on 3 different hardware types.. Dell Poweredge >>> 2650, Dell Poweredge 2850 and a HP DL380. They all worked perfectly with >>> this system and reimaged with RH40 from a single golden image. >>> Unfortunately this is as far as I can take it for the moment until >>> management has decided whether this is a better approach - they love >>> scalability and this is what they fear most of this software. >>> >>> As a side-note, in my previous email I managed to integrate a SSH daemon >>> into the imaging host to better troubleshoot issues during imaging, and >>> I've also used the XML/LOG files of si_monitor to produce much the same >>> thing as si_monitortk onto a web page (which refreshes every 30 >>> seconds.) I've already shared the SSH daemon instructions and will >>> share my code for the PHP enabled website to do monitoring from the web >>> (although we currently do not have provisions for the Virtual Console in >>> place yet - but do have plans to tie the SSH client into a java applet >>> to connect to an imaging host from the web. We love centralizing things >>> here!) and the ultimate plan being managing and monitoring all of this >>> from a single web page. I've attached a small jpg of the web monitoring >>> (very basic so far.) >>> >>> Let me know of any similar experiences you all may have had in relation >>> to this! >>> >>> Cheers, >>> >>> Jason >>> >>> >>> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sisuite-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
