David Boyes wrote:
I am talking about *two* LPARs: one is up and running, and I want a
second
test system in a separate LPAR.
Making updates and test on the test system - copying over to the
production system. Similar to the
method we also use for z/os ...
You can share DASD between Linux instances, as long as the disk is
read-
only to all Linux images that can see it.
Well that does not sound good.
Since you are in LPARs, you have limited options. You can create two
LPARs and use IPLable DDR (or ADRDSSU for z/OS or similar standalone
utilities) to make image copies from disk to disk.
Given Linux's heavy use of in-memory caching, to get a clean copy using
disk-to-disk copies, you *must* shut down the source to ensure the copy
on disk is actually what is being used. If you try to do the copies with
the test system up (ie use an active z/OS system in another LPAR to do
the copies, you will not get usable data.
Or unmount, or [re]mount read-only.
It's not a bad plan to learn Linux on a PC first - Linux is Linux, only
the hardware's different, and you can even run zSeries Linux on a PC
under hercules where you can, if you want, find what happens when you
share DASD.
You can clone a Linux image, mount the filesystem and make a few
changes
to create a new image. The trick is
knowing what to change for your Linux distribution. At a minimum,
the IP
address and host name should be changed. > If you're using zVM, then
all
the disk addresses and such can be the same for each system you set
up.
You *can* address this with system management discipline, though. You
could take a snapshot of the test system with 'tripwire', do the
updates, and generate a RPM of the change, or create a source RPM and
build/install from source both on test and production. You could then
FTP the RPM over to production and apply it with 'rpm -i' (which would
give you also an easy way to keep track of what change levels are
applied). There are some drawbacks if there are more than one group that
needs to apply stuff at a time, but if you have a well-controlled QA
process, this might do what you want.
I don't like the idea of an rpm that, as a function of being installed,
stuffs around with other stuff.
A package of tools that does that's a different matter, and YAST
provides the kind of framework I tried to badger the Nahant folks into
thinking is a Good Thing.
However, putting the tools into (say) /usr/lib/my-setup, even if it's
nothing more than a set of bash scripts, provides a central place for
them to be, and you can, as you wish, control access with sudo and POSIX
permissions. Probably selinux too, but I've not gone into that.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
----------------------------------------------------------------------
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
