[opensuse-autoinstall] Installing SLED on top of SLES
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. 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 -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Frank, I have been trying to wrap my head around why I would want to do this. I have SLED10 with SLES10 DHCP server components (and a few more) with LTSP 4.2 as well as MANY of the educational software titles in the 10.1 repo loaded on one box. Many of us have used 10.1 packages on SLES\D with out all this work. I believe, last time I checked, the SLED update channel has been maintaining all my desktop AND server packages on SLED, maybe not but, my LTSP host is running fine for 3 years now. I do the updates like its just any box. If this was an edge server , which I would hope not , I would bet adding the SLES 10 dvd, the SUSE 10.1 dvd, online repo and update channels as sources to a SLED 10 box would do the same thing as all your work. To manage the updates would simply be letting ZMD take care of the first round and your autorpm the second. While providing enough security and most importantly stability to host any internal app. If in the long run all you want from SUSE 10.1 is applications, then starting with SLED and adding the DVD's and Repo's would IMHO provide the longest term of security and broadest scope of applications because altimitely your applications specifically any web based ones are unsecure the moment there is a fix that 10.1's update channel doesn't provide. In any senario, IMHO, the value of the channel is to keep the host as stable and secure as possible beyond that we are all on the hook for third party security, why add the question of host stability to the mix. IMHO. -- James Tremblay Director of Technology Newmarket School District Newmarket NH 03857 "let's make a difference" http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Hi James, James Tremblay wrote
Frank, I have been trying to wrap my head around why I would want to do this. I have SLED10 with SLES10 DHCP server components (and a few more) with LTSP 4.2 as well as MANY of the educational software titles in the 10.1 repo
how did you install the stuff from SLES and 10.1? One of my goals was to do it automatically with AY.
loaded on one box. Many of us have used 10.1 packages on SLES\D with out all
Hmm, hasn't been so much work :-) Rsyncing a few directories, calling one script and starting AY isn't a lot work I guess :-)
this work. I believe, last time I checked, the SLED update channel has been maintaining all my desktop AND server packages on SLED, maybe not but, my
SLED does not contain updates for packages like "dhcp-server" and more stuff that's only on SLES (apache, tomcat etc.). We mirror the SLED update channel to our local hard disks and there are no such packages included. However, I said that I don't know if you can just add update channels for SLES and SLED with the SuSE mechanism, we just never it used because we've always been using autorpm (even for non-mixed installations). So I didn't say it was not possible :-)
If this was an edge server , which I would hope not , I would bet adding the SLES 10 dvd, the SUSE 10.1 dvd, online repo and update channels as sources to a SLED 10 box would do the same thing as all your work. To manage the updates
That's the point, you cannot add a SuSE DVD or SLES DVD to an AY installation of SLED other than I did. Because when you add a SLES DVD, it demands the installation of sles-release.rpm all and all packages of its base pattern. As SLED does the same, they conflict with sled-release.rpm vs. sles-release.rpm (and almost every other package of the base selection). So an automatic AY installation is not possible.
would simply be letting ZMD take care of the first round and your autorpm the second. While providing enough security and most importantly stability to host any internal app. If in the long run all you want from SUSE 10.1 is applications, then starting with SLED and adding the DVD's and Repo's would IMHO provide the longest term of security and broadest scope of applications
Starting with 10.1 has just historical reasons because we had all these 10.1 boxes and we distinguish between SuSE and SLES hosts in some hundred script by checking for /etc/SuSE-relase. For the next round we might indeed start with SLED 11, add SLES 11 the way I described it and add just some packages from opensuse 11.x and from repositories.
because altimitely your applications specifically any web based ones are unsecure the moment there is a fix that 10.1's update channel doesn't provide. In any senario, IMHO, the value of the channel is to keep the host
? Why that? I get all updates for 10.1, SLES and SLED. Almost no packages are from 10.1 that are not in SLED or SLES either. So if there is a security update in any of the three channels (10.1, SLES, SLED) I get it. It doesn't matter with which system you start (SuSE, SLES or SLED). You just get the newest packages from the set of all updates for all systems.
as stable and secure as possible beyond that we are all on the hook for third party security, why add the question of host stability to the mix. IMHO.
I guess I miss your point here. I don't rely on any third party security. I install only packages from SusE/SLES/SLED and fetch security updates for all of them. The moment the SuSE support for 10.1 is over, I have about 30 packages on my systems which are not in SLES or SLED for which I don't get security updates any more. That would be the same if I started with SLED, added SLES and some packages from SuSE manually. So what I've done here basically is: 1) setting up a system that can contain any packages from SLES, SDK, SLED (and SusE) 2) get all the security updates for SLES, SLED and SuSE and install what's matching 3) install this system automatically with AY. 1) can be done manually and in many ways. 2) can possibly be done with ZMD or whatever, I have no clue :-) But for 3) I found no other way than setting up the repository the way I did. I didn't claim this was a major breakthrough ;-) But throwing a SLES and a SLED DVD together for AY is a nice thing to have because it gives you the same huge package set the (open)SuSE provides, but with 5 years of updates, and it lets you install your hosts in one AY task. Not more and not less :-) cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
participants (2)
-
Frank Steiner
-
James Tremblay