Maybe I've just been reinventing the wheel here..
I've only one image and I use overrides per platform to get these
systems to boot... and depending on which hardware platform is being
reimaged, I create a link from the hostname -> the masterfile I've
created for that hardware platform.
snippet of our "flat file" /scratch/db/database:
------------
statest02 dell 2650
stads71 rackable C1000
stamr03 hp DL380
------------
Some snippets of my reimage.sh script I made to do all this for me:
------------
# Determine the model of our host
GETMODEL=`cat /scratch/db/database | grep $HOSTNAME | awk '{print $2$3}'`
IMAGENAME=$OS-$GETMODEL
# Setup host to reimage with the proper masterfile
cd /var/lib/systemimager/scripts
unlink $HOSTNAME.sh
ln -s $IMAGENAME.master $HOSTNAME.sh
------------
and in my /var/lib/systemimager/scripts directory: ls
------------
hosts
post-install
pre-install
RH40U3-dell2650.master
RH40U3-rackableC1000.master
RH40U3-hpDL380.master
stads71.sh --> RH40U3-rackableC1000.master
stamr03.sh --> RH40U3-hpDL380.master
statest02.sh --> RH40U3-dell2650.master
------------
The "HACK" I think I've really made is that in each master file I define
the IMAGENAME=RH40U3 as the first thing. So instead of each having their
own image, they all use the same image but I specify the OVERRIDE in
each masterfile to their respective hardware-platform-override-directory...
Phew... out of breath! I have reinvented the wheel, haven't I? :-p
Thanks for the info!
Jason
Andrea Righi wrote:
> 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
