Bug 1433372

Hi Steven,

Thank you for raising this bug.

I have read through the case notes, and understand the need for this documentation. Thank you for leaving so many detailed notes about your experience.

To address your question in the case about documentation notifications, unfortunately there is no way to currently receive notifications when one of the product documents is updated. The topic of making it easier to check when content has been updated and what was updated has come up a number of times, however, and we (the documentation department) are currently investigating a way to implement this.

I will also follow up on your proposal of a lab, and will provide feedback from the team when available.

There are a large number of open requests against the documentation at current, so we may not be able to implement the requested content in the product documentation immediately, but I will assign this out now so that we can start looking into it for you and make some progress.

Thank you once again, and let me know if there is anything else we can do for you along the way.

Kind regards,

Andrew

Assigning to Stephen for review.

(In reply to Steven Mercurio from comment #0)
> DNS Migrations for existing install TO 3'rd party FROM sat6 DNS as you need
> to change the DHCP DNS parameter handed out by DNS still handled by Sat6
> 
> and
> 
> FROM IDM/3'rd party DNS (like IP) *TO* Sat6 DNS as again additional
> parameters like DNS for DHCP need to be revisited.

Hello Steven,
I will work on adding the 'GSS-TSIG DNS' IPA DNS integration method as per BZ#1437149 as high priority.

> 
> What may actually be easier or a good addition is a chapter or section DOCd
> similar to the KS file parameters chapter for RHEL that covered each of the
> possible -- switches/parameters that can be passed to the Sat6 installer,
> what each one does, and some examples and why/when you would/would not use
> or include that parameter.
I recently opened bugs to get man pages made for the installation scripts. The tracker bug is here: BZ#1288539

> 
> Long term I see a sat6 installer GUI in the future (6.5 maybe) as there are
> so many parameters and combinations.  The firewall, kickstart, samba, and
> other configurations have gone this way and a x or curses interface would
> not be too hard to do.  an initial start would be just a RH labs gui on the
> RedHat.com site that just builds sat6 installer stanzas/scripts.
> 
> The RH labs approach would also be INVALUABLE for generating an UPGRADE
> script that can gen a script to:
> 
> 1. check that script is run from CONSOLE/screen session and advise against
> non-console or screen use for script
> 2. perform a backup (user optional)
> 3. run any rakes or prep checks (shut services cleanly and disable at start
> to let sat6 installer turn back on at boot?)
> 4. Yum update (recommend 2 step with --download only being first then
> second yum  update running from cache - EXCLUDE KERNEL THIS PASS!)
Good you explain the importance of not updating the kernel at that point?

# yum update --exclude=kernel*

> 5. run sat6 installer with correct update parameter
> 6. hammer ping, rakes, sanity checks etc.
> 7. another yum pass this time INCLUDING kernel and reboot to now get kernel
> update
> 
> and all the while sending output of the generated script (&> with specific
> echos only to console for status updates).  The advantage of RH labs
> generating this is so that you can tailor it as needed based of the version
> the user is coming from (ESPECIALLY early 6.x.y versions like 6.1.x, 6.2.0,
> 6.2.1, etc!!!).  I would expect a GUI for this is say 6.4 or 6.5 but RH
> Labs script generator will do VERY will for now!
> 
> For addl details see RH GSS case#: XXXXX

From the case I extracted this bit:

 (just using IDM for login auth to Sat6 GUI and OS level but still using "build" in named DNS) Sat6 install TO a fully connected to and using IDM (logins to GUI/OS AND DNS managing of IDM DNS as well as reg new servers to IDM)

Could you explain more about "build" ?


Thank you

I think I put this data in the RH case.  I can't seem to find it (was it closed?)  Basically though there should be procedures for taking a running Sat6 that was setup for Sat6 DNS to transition to external (like IDM) DNS and another for going from external DNS (like QIP) to Sat6 internal DNS.  There aree different steps needed like modding things in config files that need to be done that could be missed unless you happen to know where to look.

I did manage to successfully change the config file as needed for named and get DNS 100% working on IDM for Sat6.

Hello

Sorry for my typo in comment 6

s/Good you explain/Could you explain/

 the importance of not updating the kernel at that point?

On the subject of typos, when  in the support case it says "but still using build", could that be "bind" as in the daemon?

Thank you

BTW, this bug is now resolved:

Bug 1437149 - RFE - Add GSS-TSIG method to "Configuring Satellite with External IPA DNS" section of Satellite installation guide.

Configuring Satellite with External IdM DNS

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/installation_guide/configuring_external_services#configuring_satellite_external_idm_dns

Hello Steven

Can you explain more as per points in comment 8?

Thank you

Yes I meant bind.  Spell check may have tried to "help" and got that wrong or I typed it wrong.

My thought to delaying kernel was to get all Sat6 update tasks  out of the way and check that everything is working then do the kernel and reboot but if a reboot due to kernel is not disruptive to the update that line can just be taken out completely.

Hello Steve


Thank for comment 10

I am more than a little reluctant to move the reboot step without direct request from developers as it is a relatively quick step to reboot a server compared to the time it takes some customers with thousands of clients and large Pulp databases to upgrade their Satellite Server.


Thank you

Hello


 BZ#1481336 is also related to the point at which we say to reboot.

see https://bugzilla.redhat.com/show_bug.cgi?id=1481336#c1

(In reply to Stephen Wadeley from comment #11)
> Hello Steve
> 
> 
> Thank for comment 10
> 
> I am more than a little reluctant to move the reboot step without direct
> request from developers as it is a relatively quick step to reboot a server
> compared to the time it takes some customers with thousands of clients and
> large Pulp databases to upgrade their Satellite Server.
> 
> 

We are moving the reboot step as part of BZ#1481336

Hello

These last changes are now live on the customer portal.

Reverting to Internal DNS Service


https://access.redhat.com/documentation/en-us/red_hat_satellite/6.3-beta/html/installation_guide/#reverting_to_internal_dns_service