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
