[Spacewalk-list] Looking for "Best Practice" for patching base-os of Spacewalk Servers

Thu Mar 6 17:18:59 UTC 2014

Hello,

We are trying to design and deploy a highly available solution using 2 Spacewalk instances in a hot-standby configuration, comprised of:

primary - Spacewalk V2.0 server, and external Oracle 11.2 database server.
standby - Spacewalk V2.0 server, and external Oracle 11.2 database server.

The Oracle databases are kept in sync using Oracle Active Data Guard.

A separate, mrepo server contains all the packages and is updated nightly with any new rpms. The primary spacewalk server is synced regularly from this internal repository, and the /var/satellite directory is rsynched to the standby Spacewalk server.

This configuration is used to patch all our RHEL[5,6] client servers on a monthly cycle. Each month on a specific date, a static "update" channel is cloned and ALL clients use this channel to install the available security-related errata (RHSA). This keeps the client systems in synch with each other across the enterprise... and it's fairly simple and easy to implement.

QUESTION:  For patching the Spacewalk servers themselves (Base-OS only, and only the RHSA patches... at this time), what is recommended, or established as a "Best-Practice" for keeping the Spacewalk servers themselves current and synched with the rest of the enterprise?

I have my own thoughts on this, but have received other suggestions from the tech team assigned to this... I'd really appreciate any and all comments and recommendations. I searched but couldn't find documentation that covers this explicitly.. it seems very straightforward, but no consensus is coming forth from internal brainstorming discussions.

As I see it, we have these options:

1) Register each of the 2 Spacewalk servers to Spacewalk... making each one a "yum client" of the other... subscribe them to the current monthly "static" cloned channel containing the errata.  (NOTE: OSAD client daemon will NOT be installed on the Spacewalk servers)

Schedule a maintenance window and use yum to patch the "standby" server (Spacewalk services are shut-down), installing the os security errata.

Shutdown Spacewalk services on the primary, and bring them up on the (now-patched) standby Spacewalk server.

(After validation and acceptance testing is complete) Repeat the above procedure to patch the primary server.

OR,

2) Do not register each Spacewalk server, but rather, configure yum on each to pull directly from the internal mrepo server repositories.

My thoughts on the above:

* Option-1: this seems to be the most appropriate method. Spacewalk services are then used to manage the patching of the opposite server. It requires a short downtime while switching over from primary->standby and back, but keeps the Spacewalk core servers in sync with each other, AND, with all the other clients across the enterprise. The only real concern I have is what issues might be involved with having a Spacewalk server registered to itself?

* Option-2: Eliminates interaction with Spacewalk services directly, and minimizes the downtime from a switch-over, but is more difficult to synchronize the errata installed with those installed elsewhere. It also makes it difficult to fully vet the patches as a set, unless we take measures to freeze the repos for the month, or create a static repo?

I expect this has already been worked through and is probably documented somewhere, but I'm just not able to find anything that directly addresses this in an authoritative manner. If anyone has pointers or links to official documentation, whitepapers, blogs, please send them to me along with any other recommendations or gotchas or other items for consideration.

Thanks and best regards,

Whit

--
Whitney "Whit" Latta
Sr. Systems Engineer
Linux - Open Systems Engineering

--
"We've done the impossible, and that makes us mighty." ―Malcolm Reynolds
--

________________________________

The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20140306/fb320495/attachment.htm>