Frank Steiner wrote:
Hi,
a little HOWTO for people who are interested in this :-) What I do is
installing SLES and SLED on top of a SuSE 10.1 installation. Installing
SLED on SLES (or vice versa) will work the same way.
That presumes that the RPM's for SLES and the RPM's for SLED
are identical for each package.
Seems to me some things could be tweaked just a little bit
differently since the two products are aimed at substantially
different target machines (SLED providing desktop applications,
and SLES providing centralized services), and thus differing
presumptions of memory availability, chron jobs, etc.
I'm willing to bet that your frankenstein installation isn't
as coherent as you believe it to be without a LOT of checking
to prove it to be so.
I can see storing the SLED RPMs in a directory tree on your
SLES machine for local availability... installing one on
top of the other... not something I would advise others
to do without spending some significant time comparing
all of the packages on both distributions.
Why doing that? We need hosts that have the huge software repository that
you find in a (open)SuSE system but can run longer than 2 years. So my
idea was to install SLES and SLED over the SuSE system so that I replace
almost all packages with their SLES/D pendants and can use the SLES/D
security updates for a while.
This works because SuSE 10.1, SLES10 and SLED10 have a common code base.
There are a few packages that are in SuSE and not in SLES/D, very useful
ones like sshfs or wipe. Of course you can install SLES+D and add those
few packages from SuSE if you need them. Or you install SLES+D on top
of SuSE.
I describe what I did for installing SLES+D on top of SuSE 10.1. The
decision you must take is what should be your main system. In my
case, suse-release.rpm is installed, marking the system as a SuSE
system in /etc/SuSE-release. If you start with SLES and install SLED
on top, you will have sles-release.rpm, thus a SLES system + SLED
packets. If you start with SLED, you have a SLED system + SLES rpms
and sled-release.rpm.
Usually that should not be very important.
What I did (very short description because I expect that people who want to
do that know about autoyast, pxe etc.):
- made a local NFS repository for SuSE 10.1
- setup AY installation for SuSE 10.1 from that repository.
Due to some bugs in the 10.1 installer I use the SLES10 installer,
i.e. "linux" and "initrd" from the SLES10 loader/ subdir for PXE.
Note that it is not possible to use the SLES10-SP1 installed for
installing SuSE 10.1, but for combining SLES SP1 and SLED SP1.
- setup an updates/ directory below the SuSE sources with the
create_update_source.sh script from autoyast2-utils.
- rsync all RPMs from SLED-SP1, SLES-SP1 and SDK-SP1 into
that updates/ dir. I.e.,
rsync -avP <somepath>/{SLED10,SLES10,SDK10}-SP1/suse/
<somepath>/10.1/SuSE/updates/suse/
You can indeed rsync the i586 and x86_64 versions of SLES/D into
the same updates/suse/ dir. If you install SLED on SLES you don't
need that because they have seperate i586 and x86_64 versions anyway.
- in updates/suse/ call the /usr/bin/create_package_descr script like
create_package_descr -l english -l german -x `pwd`/setup/descr/EXTRA_PROV
or whatever languages you need. The script is part of autoyast2-utils, too.
- make the updates/ dir known by adding sth. like
nfs://<yourserver>/<yourpath>/10.1/SuSE/updates
to the file <yourpath>/10.1/SuSE/add_on_products
When you start AY now, it will just take the RPMs at SuSE/updates/suse/
as additional RPM repository, not knowing about SLES and SLED. To the best
of my knowledge this is the only way to solve the conflict between SuSE,
SLES and SLED. Any other method (adding the whole SLES directory as addon
product e.g.) will result in a conflict at least between suse-release.rpm,
sles-release.rpm and sled-release.rpm.
Now you can chose your packages in AY or add your own selection (if
based on SuSE) or pattern (if based on SLES) in updates/suse/setup/descr/.
Check the AY mailing list or AY homepage for further details.
One problem I stepped on: We are using lilo and with the new package set
there was some problem when AY tries to write the lilo.conf after installing
all packages. Maybe because I use the SLES10 installer to install packages
from SLES SP1. Some AY libraries seem to be incompatible there. I guess
the problem wouldn't occur when you just install SLED on SLES. For my setup
I just removed "limal-bootloader-*" from the updates/suse/ dir and it worked
again.
Now what about updates: I guess this will be a problem using the SuSE tools
because you system will identify as SuSE or SLES e.g., but you will need
updates for e.g. SLED, too. I never used the SuSE update mechanism, so I can't
tell. We have been using autorpm here for years. This is a perl script that
works on arbitrary directories (or ftp servers) and just scans all RPMs
in there, resolves dependencies and takes the latest versions of all
packages. There are many options for autorpm like upgrading only installed
packages or install all found packages, select accept or reject patterns
and so on. If you want to use that, you can find the latest patched version
at http://www.bio.ifi.lmu.de/~steiner/files/autorpm-test-3.3.3-1.noarch.rpm
because autorpm is no longer maintained by Kirk.
Anyway, any program that can work on a bunch of directories containing RPMs
without caring about the product you have installed (SuSE, SLES, SLED) should
do the job.
So we always mirror all updates for SuSE (with mirror/wget), SLES and
SLES (with yup) to our local nfs server and let autorpm work on all
three update directories. Even when SuSE 10.1 doesn't get security
updates anymore you must include the SuSE 10.1 updates for the first
update after the installation.
If you install SLED on SLES you don't care about this of course ;-)
I'm sure you can also rsync the updated RPMs from SuSE/SLES/SLED into
the SuSE/updates/suse/ repository so that AY works always on all the
latest updates. I just didn't do that to have a stable repository for
installation to make sure it always runs the same way.
There are other ways to achieve the same result, like adding repositories
to your either SLED or SLES installation, however, if you need a full
SLES+SLED set on some of your hosts, I guess this is the easiest way.
cu,
Frank
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
