While working with a customer today, we were solving some silly problems that cropped up while patching his OES2sp1 Linux servers. Some nonsense about Mozilla dependencies on 64-bit servers (see Novell TID 7004278 for details on that). But that’s not what I’m here to discuss today…
Anyway, since SLES10sp3 came out in the past few days, a simple behavior has come to my attention. If you run “zypper up” on a standard SLES server, for instance, it will perform the “move-to-sles10-sp3” patch and do what it sounds like it will do. This is a good thing on a SLES server as far as I can tell so far. Even my iFolder 3.7.2 seems to love sp3.
Also, I’ve patched a small handful of OES2sp1 servers using the command “rug up -t patch OES2-SP1-Updates SLES10-SP2-Updates“. And (until today) by default, they did *not* perform the “move-to-sles10-sp3” as one would expect them not to, since it might break the OES2sp1 install in some ways that I don’t know or want to know.
So today, the third OES2sp1 server we were patching today suddenly prompted me with the *warning* (to which I must agree to continue) that it was going to do the migration to sp3! Argh! I scrolled back up to see the list of patches, and it did even have the “move-to-sles10-sp3” patch in the list. Hmm… Okay, that scared me enough. A quick “rug lu” shows that it is still listed as an optional patch… Hmm…
Honestly, I’m not sure what is going on here, but I wanted to make sure my regular readers/customers/friends are aware of this (if you’re an enemy of mine, go ahead and install it and tell me how it goes…), and warn that as far as I can tell, running sp3 underneath OES2sp1 is not a good (or supported) thing. Not until OES2sp2, from what I understand.
So I want to update the recommendation I’ve made here in the past. My new preferred method of patching OESsp2-Linux servers is this:
rug up -t patch -g security -g recommended
…or optionally specify the channels too…
rug up -t patch -g security -g recommended OES2-SP1-Updates SLES10-SP2-Updates
By specifying the “security” and “recommended” types, you avoid the “optional” type, which is where the “move-to-sles10-sp3” update resides.
In the end, no matter what we did with this one server, it still tried to do the “move-to-sles10-sp3“. So we kinda’ threw in the towel and ran the “Desktop Updater” from the GUI, which is Novell’s only other recommend method of installing updates. And *it* did not prompt us to accept the sp3 update, just standard kernel warnings. Phew!
If you know more about this, please share with us. Also, I’ll update this post as discover more… Good luck out there…
😛
Updates: SLES10SP3 Release notes, Press Release, …
Pingback: Your Linux Guy .com » Blog Archive » Slow RUG/ZMD on OES2 in the Enterprise?
Hi Jeremy,
I have to write to you following reading your latest blog where you mention having iFolder 3.7.2 running on SLES10 SP3….
I have put in my fair share of hours trying to get iFolder 3.7.2 to run on all versions of SLES10, all to no avail.
Have you created a crib sheet for an install of iFolder 3.7.2?
I could dearly do with a few pointers…I just can’t find a combination of downloads and settings that function as a working iFolder server.
Best wishes
Stan Chelchowski
@Stan
Well, I’ll be… I had meant to follow-up with an iFolder 3.7.2 cheat-sheet, but I now realize that I have not done so yet. So, that will be my next post. I have all my notes handy from my last install (the one on the now-sp3 server), so it won’t be that much for me to whip together….
🙂