Monthly patching content view organization with Satellite 6.2
Hello guys,
Currently we are using Satellite 5 and I'm migrating it to Satellite 6. With Satellite 5 our practice is to create a clone of the master channel with updates til 1st day of the month and apply it to each server for the current month e.g.this way all servers patched in April will have same packages installed. We do it that way ever month. My question is can you suggest how I can achieve that with Satellite 6?
Responses
Expert
823 points
This is exactly what "Content Views" are for in Satellite 6. We patch most of our servers every month, so we have 3 Content Views (one for each major RHEL version - rhel5, rhel6, rhel7), and 3 "LifeCycle Environments" - the default "Library" environment is for test systems with no users, "Test" for systems that are used by developers /application administrators to build their applications and verify new RHEL patches, and "Production". Each month, the "Library" and "Test" Environments are updated ("publish a new Version of the Content View" in Satellite 6 terminology, - that makes the newest patch set available to the Library Environment, then 'Promote' it to the "Test" Environment. A week after the Test systems are patched, the new version of the Content View is promoted to the "Production" Environment. Any time new servers are deployed, they get the exact same patch set as every other system in the same Environment & Content View (e.g. RHEL 7 Production).
You can create simpler or more complex scenarios to fit your needs (2 Environments only, or 4 if you need to separate "Dev", "Staging", "QA", and "Production" systems). The "Content Management Guide" for Satellite 6 includes detailed documentation on how to setup up Lifecycle Environments, Content Views, and Managing Errata (patches); see https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/
Red Hat
Guru
2305 points
This. ^^^ Content Views & Lifecycle environments were modelled after the 'clone channel' workflows from Satellite 5:
Users usually fall into one of two disciplines:
- define the workflow and move content to the systems.
- define the content and create a workflow to move the systems to the content.
The former is the Content Views + Lifecycle Environments approach mentioned above. Alternatively, you can just create point-in-time snapshots whenever you like and move systems between them as needed.
Is there an advantage to separating RHEL versions into different content views? I would think this just adds to your maintenance. Why not keep it simple? We use 2 main content views, all_rhel (all rhel products) and local_and_3rdparty (In house and 3rd partly repos). These make up a single composite content view which we promote through Lib, Dev, Test and Prod. We don't use filters, maybe we should?
Community Member
72 points
First thank you for the responses. We decided to use only the Library environment and my plan is to create 3 content views for each RH version as James said and publish new version of the content views each month. Do you think that is a good idea, should I use some filters to the content view?
Red Hat
Guru
2305 points
Without a filter, what content ends up in your content view is a matter of WHEN you publish it. With filters, regardless of when you publish the content view, it will only have what your filters define. I prefer filters as they allow me to be more explicit about what content is in the content view. See this document for more notes on filters.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.