search

SUSE / suse-migration-services

GNU General Public License v3.0
7 stars 11 forks source link

SUSE migration services pre-check for lingering `smt-ec2.susecloud.net` /etc/hosts entries #291

Open thimslugga opened 2 months ago

thimslugga commented 2 months ago

The SUSE migration services pre-checks should check for lingering smt-ec2.susecloud.net entries in the /etc/hosts file, where the host is actually connected directly to the SCC and using updates.suse.com. It should warn for these lingering /etc/hosts entries as they can cause issues during SUSE dist migration activities.

schaefi commented 1 week ago

I do not understand the negative impact for the DMS if the connection to the SUSE repositories is established via the public cloud infrastructure (RMT proxy) or a direct connection to SCC or any other form of proxy connection ? Is it a responsibility of the DMS pre-checks to guess on the connectivity setup ? Unless there is a direct coupling between code in DMS and the way how to connect to the suse update server(s) we should not add a pre-check.

The DMS connects to suse repos in two ways:

  1. via zypper dup and locally configured repositories. A zypper refresh prior starting the DMS is suitable to detect any connection issues
  2. via the zypper migration plugin. I'm not aware that the API call to the SCC backend differentiates if the call is made to SCC or a proxy.

From that perspective if you believe we need a check, can you be more specific on what "can cause issues" mean ?

Thanks

rjschwei commented 1 week ago

During migration everything is driven by the information that is in the RIS files. The only issue I could see with a system that was once connected to the update infrastructure and then switched to point to SCC is that a specific RIS file, a file in /etc/zypp/services.d points to the update infrastructure while other files point to updates.suse.com. If that is the case then that would be a bug in registercloudguest --clean. What we can check, as a pre-check, is that there is no mix between *.susecloud.net and updates.suse.com in the files contained in /etc/zypp/services.d. Meaning, for example the service for the Basemodule points to susecloud.net and for the Public-Cloud-Module points to updates.suse.com, such an inconsistent setup would definitely create problems.

thimslugga commented 1 week ago

@rjschwei, related https://github.com/SUSE/connect-ng/issues/242

@schaefi, A lingering smt-ec2.susecloud.net hosts entry that wasn't cleaned up, where the customer has switched to updates.suse.com will result in attempts to dist upgrade via DMS to fail.

schaefi commented 5 days ago

What we can check, as a pre-check, is that there is no mix between *.susecloud.net and updates.suse.com in the files contained in /etc/zypp/services.d

Thanks much for the details, yes that makes sense and could be pre-checked