To get the parameters for self-configuring I was thinking of having the rescue system read them from a CMS file using Rick Troth's CMSFS utility functions. The dead server's unique CMS parm file could be created by hand in advance, or populated once or periodically by some type of export process from the live server. For an IP address I'm thinking the rescue system can just use the dead server's 'admin lan' address probably similar function to your 'service' lan.
Instead of basing the rescue system on the starter system I'd like to just copy and convert an existing "full-fledged" server; and make it maintainable by Yast Online Update. That way I could easily add and maintain any packages I need for our environment, like the TSM restore client. When I boot the rescue system off R/W disk I can update it; when I boot it off R/O disk it assumes its rescue role. -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, September 29, 2006 9:46 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: R/O dasd + ramdisk rescue system On 9/29/06, Romanowski, John (OFT) <[EMAIL PROTECTED]> wrote: > Has anyone implemented Rob van der Heij's idea about a read-only-dasd > rescue system that run's from ramdisk? I don't want to reinvent the > wheel if someone's documented how they did it. We did not finish that work because we found in our shop the approach of linking to the dead penguin's disks much more attractive for various reasons. With the SuSE starter system you have most of it. You can use zipl to write the kernel image, parmfile and initrd to a small disk. If you IPL that you get the "install" starter system. The rest of it would be in /linuxrc and maybe some packages you must add to the initrd. The biggest hurdle in the system's self-configuring is getting the IP configuration. Once you have that you can go to LDAP or even do a wget against a web server to get all the details. We have discussed on the list various ways to do that. What I used myself was a separate "service" guest LAN that each server couples to. On that guest LAN you run your own virtual DHCP server that uses a fixed table to assign IP address based on the MAC address in the directory. In theory it should be good enough to have a fixed IP address for the penguin in rescue mode (do you really expect to run several in rescue mode at the same time). However, we learned that the YaST configuration was not really designed towards an approach where you have a different network location during system installation. To have a separate service IP address seems to be a good alternative if you want to avoid connecting the system to the bad Internet while you're still doing the install and testing things. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
