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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org