SLES12sp2 - Zypper trying to authenticate in an offline env

SUSE Linux Enterprise Server SLES Updates
1

Hi,

I have a local SMT repository that is snyc’d to the Suse repositories, and then I clone it into an offline environment with local clients pointed at it for updates. I have had no issues doing this with SLES11 hosts, but today I am trying on a SLES12 box and zypper wants to authenticate on SCC to confirm registration. Since this is a production environment and this will never be possible, looking for guidance on how to stop this? IS there a way around it?

ex:

sles12-base-01:/etc/zypp/repos.d # zypper lp Refreshing service 'SUSE_Linux_Enterprise_Server_12_SP2_x86_64'. Authentication required for 'https://scc.suse.com/access/services/1346?cookies=0&credentials=SUSE_Linux_Enterprise_Server_12_SP2_x86_64' User Name: SCC_ab3************ Password: Problem retrieving the repository index file for service 'SUSE_Linux_Enterprise_Server_12_SP2_x86_64': Login failed. (https://scc.suse.com/access/services/1346/repo/repoindex.xml?cookies=0&credentials=SUSE_Linux_Enterprise_Server_12_SP2_x86_64): The requested URL returned error: 401 Check if the URI is valid and accessible.

I am a little confused with why it is trying to hit that repo as it is not one that is defined/enabled.

[CODE]sles12-base-01:/etc/zypp/repos.d # zypper lr -u
Repository priorities are without effect. All enabled repositories share the same priority.

| Alias | Name | Enabled | GPG Check | Refresh | URI

–±------------------±------------------±--------±----------±--------±---------------------------------------------------------------------------
1 | SLES12sp2-Updates | SLES12sp2-Updates | Yes | (r ) Yes | Yes | http://192.168.1.100/repo/full/SUSE/Updates/SLE-SERVER/12-SP2/x86_64/update/[/CODE]

Thx for any help!

2

Hi
So what files are in /etc/zypp/? Sounds like you registration with the SMT system didn’t work (that appears just to be a plain repo?), or the system was initially setup with SCC?

Can you show the full list of repositories?

zypper lr -d

How did you register the system with SLES12sp2-Updates?

3

[CODE]sles12-base-01:/etc/zypp # zypper lr -d
Repository priorities are without effect. All enabled repositories share the same priority.

| Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service

–±------------------±------------------±--------±----------±--------±---------±-------±----------------------------------------------------------------------------±-------
1 | SLES12sp2-Updates | SLES12sp2-Updates | Yes | (r ) Yes | Yes | 99 | rpm-md | http://192.168.1.100/repo/full/SUSE/Updates/SLE-SERVER/12-SP2/x86_64/update/ |
[/CODE]

So I just followed the same steps I did with the 11 hosts. I disabled all the default repos that come set up on the host because we can’t reach them anyhow. Then I used Yast to add a new repository. At first I tried via URL and then when I saw that it was trying to register, I thought maybe it was something with how I added the repo so I redid it as just HTTP.

These systems will never be able to reach out and register with SCC. Like I said, the SMT was initially set up in an online environment, then I cloned it into our production environment.

Thx.

4

[QUOTE=mleblancdp;51004][CODE]sles12-base-01:/etc/zypp # zypper lr -d
Repository priorities are without effect. All enabled repositories share the same priority.

| Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service

–±------------------±------------------±--------±----------±--------±---------±-------±----------------------------------------------------------------------------±-------
1 | SLES12sp2-Updates | SLES12sp2-Updates | Yes | (r ) Yes | Yes | 99 | rpm-md | http://192.168.1.100/repo/full/SUSE/Updates/SLE-SERVER/12-SP2/x86_64/update/ |
[/CODE]

So I just followed the same steps I did with the 11 hosts. I disabled all the default repos that come set up on the host because we can’t reach them anyhow. Then I used Yast to add a new repository. At first I tried via URL and then when I saw that it was trying to register, I thought maybe it was something with how I added the repo so I redid it as just HTTP.

These systems will never be able to reach out and register with SCC. Like I said, the SMT was initially set up in an online environment, then I cloned it into our production environment.

Thx.[/QUOTE]
Hi
So I wonder if there is some maintenance required on the SMT system, not enough/expired licenses etc…?

If you look on one of the other working hosts, what files/contents are in /etc/zypp/credentials.d/ are they the same on a working system compared to this system?

5

Tried copying the creds from a working host, no luck. It does parse out the username, but prompts for password and even if I paste in the correct value it is rejected.

What I don’t understand is what is causing it to try and reach out to the SCC to authenticate? I feel like if I could find where that is being called I could solve this.

sles12-base-01:~ # zypper lp Refreshing service 'SUSE_Linux_Enterprise_Server_12_SP2_x86_64'. [COLOR="#FFFF00"]Authentication required for 'https://scc.suse.com/access/services/1346?cookies=0&credentials=SUSE_Linux_Enterprise_Server_12_SP2_x86_64' [/COLOR]User Name: 69f55e90eb60487886ec791b3e4497f9 Password: Problem retrieving the repository index file for service 'SUSE_Linux_Enterprise_Server_12_SP2_x86_64': Login failed. (https://scc.suse.com/access/services/1346/repo/repoindex.xml?cookies=0&credentials=SUSE_Linux_Enterprise_Server_12_SP2_x86_64): The requested URL returned error: 401 Check if the URI is valid and accessible.

6

Hi
So there must be a SCCcredentials file in /etc/zypp/credentials.d/? Is
this the same on a working system?

You might try cleaning up the repos with;

zypper clean -a
zypper ref -f

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.3|GNOME 3.20.2|4.4.114-42-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

7

So the culprit was a service being loaded from /etc/zypp/services.d/ .

Ultimately I discovered this while working on a different problem on a different server, but your pointing me to the credentials.d directory is what pointed me in the right direction.

All I had to do was remove the service file and away it went.

Thanks!