[Spacewalk-list] base patch or latest

[Daniel Eather]

Hi Avi,

Wow, some great info there, thanks a lot. We were stuck unfortunately at 6.5 as Ops Center 12.2.2 only supported OL 6.5. Now with the release of 12.3.1 it supports up to Oracle Linux 7, but only provisioning, not patching! Which means we had to abandon patching from Ops Center and look elsewhere (insert SpaceWalk!).

Yep, we're on SpaceWalk 2.2. It's fantastic news Oracle are looking to release 2.4 soon....any rough ideas on an ETA? I only ask because this instance of SpaceWalk is POC, and I'd consider hanging off releasing it to Ops if 2.4 was not too far away :)
We only have basic support for our Linux stuff, so unfortunately no ksplice for us (as much as I would _love_ to use it, there's no room in the budget at the moment).

Thanks again for the information, I had kicked off a "latest" sync and did notice it was HUGE. I've since cancelled it, I'll take your advice and add in all the patch channels.

Cheers,
Dan


From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Avi Miller
Sent: Tuesday, 23 February 2016 7:25 PM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] base patch or latest

Hi,

On 23 Feb 2016, at 3:06 PM, Daniel Eather <daniel.eather at cranegroup.com.au<mailto:daniel.eather at cranegroup.com.au>> wrote:

I had thought a reaonsable way to patch would be to clone the base and patch channels as at a date, and then apply those cloned channels to my list of servers. However, what would be the difference between doing this and just cloning the latest channel and applying it? Any advantages to doing this, or should I stick with cloning base and patch?

Latest is actually everything, i.e. it contains every version of every package ever released. Which means it is HUGE. So, if you sync latest, it'll take a very long time and it's a nightmare to clone without lots and lots of memory for Spacewalk.

On the other hand, base and patch are only valid for the life of that update cycle. Once a new patch channel is created, the old ones are no longer updated. So, if you sync base/patch for OL6U5 for example,that u5_patch channel has not been updated after u6 was released. Therefore, if you keep your systems at that level, you have none of the security errata that have been released since. And that's a LOT of security errata, including most of the big ones.

So, overall I recommend working out what's the most effective for your environment. You will need either latest or all the patch channels to ensure you're up-to-date with security patches. If you have Oracle Linux Premier Support, I strongly recommend using the -n (latest packages) option for the Ksplice Offline repo as well.

You don't mention what version of Spacewalk you're running, but I assume it's 2.2 so that you get support from Oracle. We are very close to releasing 2.4 as well and that comes with a really nice enhancement to repo syncing that allows you to flag a channel to only sync the latest packages in the upstream repo. This can be used with our "latest" repos to dramatically reduce the overall sync size/time. But, if you upgrade to "latest", you'll be on OL6U7 (as you should be, quite frankly).

My general advice is to ignore the .Y and just think of it as Oracle Linux 6. So, either use latest and stay up to date or move from patch level to patch level as they become available, to ensure you are always secure. Oh, and use Ksplice, it's amazing. :)

Cheers,
Avi

______________________________________________________________________
Any views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of 
Fletcher Building or any related subsidiaries.
--
Oracle <http://www.oracle.com>
Avi Miller | Product Management Director | +61 (3) 8616 3496
Oracle Linux and Virtualization
417 St Kilda Road, Melbourne, Victoria 3004 Australia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160223/b8d7cb3f/attachment.htm>