Hide Forgot
Document URL: https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.1/html/User_Guide/index.html Section Number and Name: I feel like the guide kind of skips how to sync repositories in the satellite, it skips to how to add repos to a content view. Describe the issue: doesn't cover why you need to sync the base repos Suggestions for improvement: Additional information: We have many cases with "I'm missing packages that should be in the rhel 7 repository" or any repository on my clients. 99% of the time we check the webui, and only the Red Hat Enterprise Linux 7 Server RPMs x86_64 7.1 for example. not the rhel 7 SERVER. Once we explain this it makes sense, but since the base repo is at the bottom of the list its easy to forget ( obviously can make an RFE for the base to be at the top) but for now, it be nice to have it in the guide. Example from the webui. Red Hat Enterprise Linux 7 Server (RPMs) Enabled? Repository Red Hat Enterprise Linux 7 Server RPMs x86_64 7.0 Red Hat Enterprise Linux 7 Server RPMs x86_64 7.1 Red Hat Enterprise Linux 7 Server RPMs x86_64 7.2 NEEDS TO BE CHECKED -->Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server I feel if this is documented a tad better and maybe even explain what the difference is between syncing just the 7.2 ( bc that's the latest ) and rhel 7 server.
I've got a chapter on synchronizing Red Hat content (plus one for custom content), including a section on synchronizing repos: https://access.redhat.com/documentation/en/red-hat-satellite/version-6.2-beta/content-management-guide/#Importing_Red_Hat_Content-Selecting_Red_Hat_Repositories_to_Synchronize Kathryn, is this what you were looking to add? Any further content I should add to this section?
(In reply to Dan Macpherson from comment #1) > I've got a chapter on synchronizing Red Hat content (plus one for custom > content), including a section on synchronizing repos: > > https://access.redhat.com/documentation/en/red-hat-satellite/version-6.2- > beta/content-management-guide/#Importing_Red_Hat_Content- > Selecting_Red_Hat_Repositories_to_Synchronize > > Kathryn, is this what you were looking to add? Any further content I should > add to this section? This is really nice thank you, what i think is missing from it is literally why you are syncing the rhel 7 server even though you want your systems on 7.2 ( yes its bc the latest packages are in server).. what happens is people only select 7.2 then packages are missing from there repositories bc they never select 7 server. The example I don't think goes with what we are just asking to explain why you sync the "base" repo in addition to the minor one that you want. Here's an example ( ignore the eus part) but look at step 3. https://access.redhat.com/solutions/1461203 Hope that helps clarify, just maybe need the same disclaiming that we added in the kcs. You want 7.2 awesome, but sync 7 server as well.
Thanks, Kathryn. I've added some more info regarding the distinction between 7 server vs 7.2. I'll update the beta and send you a link.
Here's the link: https://access.redhat.com/documentation/en/red-hat-satellite/version-6.2-beta/content-management-guide/#Importing_Red_Hat_Content-Selecting_Red_Hat_Repositories_to_Synchronize See the descriptions in the table for 4.5. Selecting Red Hat Repositories to Synchronize How does that look now?
I think what Kathryn is getting at is that the end user is unaware of the lifecycle of each repository (7.2 versus 7Server), and it is not entirely obvious from the UI. As such we need to guide them a little better in the docs. If I expand Red Hat Repositories->Red Hat Enterprise Linux Server-> Red Hat Enterprise Linux 7 Server (RPMs), it get a listing of repositories: Red Hat Enterprise Linux 7 Server RPMs x86_64 7.0 Red Hat Enterprise Linux 7 Server RPMs x86_64 7.1 Red Hat Enterprise Linux 7 Server RPMs x86_64 7.2 Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server Which do I choose? Well, as an uninformed user, I'll say 'My systems are currently 7.2, so syncing the 7.2 repo makes a whole lot of sense' However, there are a lot of caveats with using that 7.2 repo. 1 - When 7.3 ships, that repo no longer receives any errata. 2 - because of [1], the end user is lulled into a false sense of security. (There are no applicable errata, thus I believe I am 'safe'). 3 - If/when a post-7.2 errata is shipped that the user wants, they'll have to republish their content views with a new repo (a 7.3 repo or the 7Server repo) in order to make that content available. 4 - Due to [3], the customer ends up opening a support case to get help with getting that errata that they want, which if we can guide them better practices re: repository management, we can avoid a case being opened. Thus, our recommendation should be: use the 7Server repo (with content view filters if needed), because > 90% of the time, it is the best option. Use the 7.2 (and other dot-release repos) if you know what you are doing and are aware of the caveats This is detailed is much more detail in this KCS - https://access.redhat.com/articles/1586183.
(In reply to Rich Jerrido from comment #5) > I think what Kathryn is getting at is that the end user is unaware of the > lifecycle of each repository (7.2 versus 7Server), and it is not entirely > obvious from the UI. As such we need to guide them a little better in the > docs. > > If I expand Red Hat Repositories->Red Hat Enterprise Linux Server-> Red Hat > Enterprise Linux 7 Server (RPMs), it get a listing of repositories: > > Red Hat Enterprise Linux 7 Server RPMs x86_64 7.0 > Red Hat Enterprise Linux 7 Server RPMs x86_64 7.1 > Red Hat Enterprise Linux 7 Server RPMs x86_64 7.2 > Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server > > Which do I choose? Well, as an uninformed user, I'll say 'My systems are > currently 7.2, so syncing the 7.2 repo makes a whole lot of sense' > > However, there are a lot of caveats with using that 7.2 repo. > > 1 - When 7.3 ships, that repo no longer receives any errata. > 2 - because of [1], the end user is lulled into a false sense of security. > (There are no applicable errata, thus I believe I am 'safe'). > 3 - If/when a post-7.2 errata is shipped that the user wants, they'll have > to republish their content views with a new repo (a 7.3 repo or the 7Server > repo) in order to make that content available. > 4 - Due to [3], the customer ends up opening a support case to get help with > getting that errata that they want, which if we can guide them better > practices re: repository management, we can avoid a case being opened. > > Thus, our recommendation should be: use the 7Server repo (with content view > filters if needed), because > 90% of the time, it is the best option. Use > the 7.2 (and other dot-release repos) if you know what you are doing and are > aware of the caveats > > This is detailed is much more detail in this KCS - > https://access.redhat.com/articles/1586183. +1 this is exactly what we are saying =D
A new bug - BZ#1425481 - has been raised asking for similar clarification regarding repository life cycles. I will close this bug, and use the new bug as a tracker for this content, noting that the comments in this must also be taken into account.