Hello everyone,
I’m running SLES 12.3 on s390x Linux 4.4.162-94.72-default, on running docker container, the zypper refresh or similar commands to fetch package/repository always fails with the error
Refreshing service 'container-suseconnect'.
Problem retrieving the repository index file for service 'container-suseconnect':
[container-suseconnect|file:/usr/lib/zypp/plugins/services/container-suseconnect]
Warning: Skipping service 'container-suseconnect' because of the above error.
All services have been refreshed.
Warning: There are no enabled repositories defined.
Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories.
working on docker image suse/sles12
docker verssion
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.7
Git commit: e68fc7a215d7
Built: Wed Dec 19 10:26:55 2018
OS/Arch: linux/s390x
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.7
Git commit: e68fc7a215d7
Built: Tue Aug 21 17:16:31 2018
OS/Arch: linux/s390x
Experimental: false
Hello Vaibhav,
Are you doing this on a LinuxOne Community Cloud system?
Mike
Hello Mike,
Yes I’m using community cloud system
I started looking at this and remembered that I had answered a similar question in an email to the L1CC administrator in March 2017. I was unable to find the thread where the administrator posted a note on the L1CC forum. So I decided to revisit my response, updating it since things have changed with the newer docker version.
You will see the following reason for the error by looking in /var/log/suseconnect.log in your container. One of the last lines in the error file is:
2019/01/22 23:34:20 Get https://148.100.42.9/connect/subscriptions/products?arch=s390x&identifier=SLES&version=12.2: x509: certificate signed by unknown authority
The reason is because the docker container is attempting secure communication to the repo server being hosted by the L1CC. The repo server is using a self signed certificate which is not trusted by the container.
To complicate matters, the repo server hosted by the L1CC is no longer hosting SLES12 repos. Even if we get the trust anchor added, the SLES12 container image will not find the repos it is looking for. Currently SLES12 SP1 through SLES12 SP3 is hosted on the repo server.
One more wrinkle is that docker containers can use DNS servers for name resolution but not a local hosts file on the docker host. The repo server, lxslsmt, is not being resolved from DNS but rather /etc/hosts on the docker host. How to work around this has changed for the better since I replied to the L1CC administrator in 2017.
So I will show how the trust anchor can be added to a SLES12 SP3 image and enable the container to resolve lxslsmt.
- Pull the SLES12 SP3 container image from the SUSE registry
docker pull registry.suse.com/suse/sles12sp3:latest
- Create /root/sles12sp3/Dockerfile on the docker host
FROM registry.suse.com/suse/sles12sp3
# IMPORTANT: MUST HAVE --add-host lxslsmt:148.100.42.9 IN OPTIONS FOR DOCKER BUILD AND RUN COMMANDS
# WHEN USING THIS IMAGE
# Import the crt file of the L1CC SMT server
ADD http://lxslsmt/smt.crt /etc/pki/trust/anchors/smt.crt
RUN update-ca-certificates
RUN zypper --gpg-auto-import-keys ref -s
- Build an updated SLES12 SP3 container image that will be used for future container work
docker build --add-host lxslsmt:148.100.42.9 -t suse/sles12sp3:2.0.0 /root/sles12sp3/
- You will now see a suse/sles12sp3 docker image that you can use. Be sure to add
--add-host lxslsmt:148.100.42.9 to future docker run or docker build commands. If you forget this then zypper commands will fail!
1 Like
Thank you Mike, your explanation and solution is amazing. Critical information like this should have blog. It solved the issues.
Hello Everyone,
My environment: host OS: SLES 12 SP4, base image: registry.suse.com/suse/sles12sp4
I was getting the same error and i tried the same solution but it didn’t work for me. I also tried it on sles12sp3 and i was getting the error: ADD failed: Get http://lxslsmt/smt.crt: dial tcp: lookup lxslsmt on 10.30.48.37:53: server misbehaving
I am trying to install nfs-client inside the container. I tried 2 solution:
- zypper addrepo https://download.opensuse.org/repositories/openSUSE:Leap:15.1:Update/standard/openSUSE:Leap:15.1:Update.repo
zypper refresh
zypper install nfs-client
After running the “zypper install nfs-client” i got 2 option:
Problem: nothing provides libtirpc.so.3()(64bit) needed by nfs-client-2.1.1-lp151.7.3.1.x86_64
Solution 1: do not install nfs-client-2.1.1-lp151.7.3.1.x86_64
Solution 2: break nfs-client-2.1.1-lp151.7.3.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] ©: 2
If I go with option 1, it won’t install the nfs-client.
If i choose option 2 it will install the nfs-client, but when i try to mount the nfs share i am getting below error:
sh-4.3# mount -t nfs -o “vers=3,nolock” 10.31.237.160:/ifs/nfscp /mnt/temp/
/sbin/mount.nfs: error while loading shared libraries: libtirpc.so.3: cannot open shared object file: No such file or directory
- I also tried to install it offline but it failed there too.
sh-4.3# rpm -ivh nfs-client-2.1.1-lp151.7.3.1.x86_64.rpm
warning: nfs-client-2.1.1-lp151.7.3.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY
error: Failed dependencies:
group(nogroup) is needed by nfs-client-2.1.1-lp151.7.3.1.x86_64
keyutils is needed by nfs-client-2.1.1-lp151.7.3.1.x86_64
libdevmapper.so.1.03()(64bit) is needed by nfs-client-2.1.1-lp151.7.3.1.x86_64
libdevmapper.so.1.03(Base)(64bit) is needed by nfs-client-2.1.1-lp151.7.3.1.x86_64
Don’t know where is the problem.
Regards,
C P