Coder Social home page Coder Social logo

container-suseconnect's Introduction

container-suseconnect Golang Tests GoDoc

container-suseconnect provides a ZYpp service plugin, a ZYpp url resolver plugin and command line interface.

It gives access to repositories during docker build and run using the host machine credentials.

Command line interface

The application runs as ZYpp service per default if the name of the executable is container-suseconnect-zypp. It will run as a ZYpp URL resolver if the name of the executable is susecloud. In every other case it assumes that a real user executes the application. The help output of container-suseconnect shows all available commands and indicates the current defaults:

container-suseconnect -h
NAME:
   container-suseconnect - Access zypper repositories from within containers

USAGE:
   This application can be used to retrieve basic metadata about SLES
   related products and module extensions.

   Please use the 'list-products' subcommand for listing all currently
   available products including their repositories and a short description.

   Use the 'list-modules' subcommand for listing available modules, where
   their 'Identifier' can be used to enable them via the ADDITIONAL_MODULES
   environment variable during container creation/run. When enabling multiple
   modules the identifiers are expected to be comma-separated.

   The 'zypper' subcommand runs the application as zypper plugin and is only
   intended to use for debugging purposes.

VERSION:
   2.3.0

COMMANDS:
   list-products, lp  List available products (default)
   list-modules, lm   List available modules
   zypper, z, zypp    Run the zypper service plugin
   help, h            Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --help, -h     show help (default: false)
   --version, -v  print the version (default: false)

COPYRIGHT:
   © 2020 SUSE LCC

Logging

By default, this program will log everything into the /var/log/suseconnect.log file. Otherwise, you can optionally specify a custom path with the SUSECONNECT_LOG_FILE environment variable. To retrieve the contents of the log, you will have to mount the needed volume in your host.

You can do this with either the VOLUME instruction in your Dockerfile, or with the -v parameter when running docker run. Read more about this here.

Finally, if neither the default /var/log/suseconnect.log file nor the file specified through the SUSECONNECT_LOG_FILE environment variable are writable, then this program will log to the standard error output by default.

Example Dockerfile

Creating a SLE 15 Image

The following Dockerfile creates a simple container image based on SLE 15:

FROM registry.suse.com/suse/sle15:latest

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in vim

When the Docker host machine is registered against an internal SMT server, the Docker image requires the SSL certificate used by SMT:

FROM registry.suse.com/suse/sle15:latest

# Import the crt file of our private SMT server
ADD http://smt.test.lan/smt.crt /etc/pki/trust/anchors/smt.crt
RUN update-ca-certificates

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in vim

Creating a Custom SLE 15 SP5 Image

The following Dockerfile creates a simple container image based on SLE 15 SP5:

FROM registry.suse.com/suse/sle15:15.5

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in vim

After registering the host machine against an internal SMT server, the Docker image requires the SSL certificate used by SMT:

FROM registry.suse.com/suse/sle15:15.5

# Import the crt file of our private SMT server
ADD http://smt.test.lan/smt.crt /etc/ssl/certs/smt.pem
RUN c_rehash /etc/ssl/certs

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in vim

All recommended package modules are enabled by default. It is possible to enable additional non-recommended modules via the identifier by setting the environment variable ADDITIONAL_MODULES. When enabling multiple modules the identifiers are expected to be comma-separated:

FROM registry.suse.com/suse/sle15:latest

ENV ADDITIONAL_MODULES sle-module-desktop-applications,sle-module-development-tools

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in gvim

Examples taken from https://documentation.suse.com/sles/12-SP4/html/SLES-all/docker-building-images.html#Customizing-Pre-build-Images

Building images on SLE systems registered with RMT or SMT

When the host system used for building the docker images is registered against RMT or SMT it is only possible to build containers for the same SLE code base as the host system is running on. I.e. if you docker host is a SLE15 system you can only build SLE15 based images out of the box.

If you want to build for a different SLE version than what is running on the host machine you will need to inject matching credentials for that target release into the build. For details on how to achieve that please follow the steps outlined in the Building images on non SLE distributions section.

Building images on-demand SLE instances in the public cloud

When building container images on SLE instances that were launched as so-called "on-demand" or "pay as you go" instances on a Public Cloud (as AWS, GCE or Azure) some additional steps have to be performed.

For installing packages and updates the "on-demand" public cloud instance are connected to a public cloud specific update infrastructure which is based around RMT servers operated by SUSE on the various Public Cloud Providers.

To be able access this update infrastructure instances need to perform additional steps to locate the required services and authenticate with them. More details on this are outlined in a Blog Series on suse.com starting here.

In order to build containers on this type of instances a new service was introduced, that service is called containerbuild-regionsrv and will be available in the public cloud images provided through the Marketplaces of the various Public Cloud Providers. So before building an image this service has to be started on the public cloud instance

systemctl start containerbuild-regionsrv

In order to have it started automatically (e.g. after reboot) please use:

systemctl enable containerbuild-regionsrv

The zypper plugins provided by container-suseconnect will then connect to this service for getting authentication details and information about which update server to talk to. In order for that to work the container has to be built with host networking enabled. I.e. you need to call docker build with --network host:

docker build --network host <builddir>

Since update infrastructure in the Public Clouds is based upon RMT, the same restrictions with regard to building SLE images for SLE versions differing from the SLE version of the host apply here as well. (See above)

Building images on non SLE distributions

It is possible to build SLE based docker images on other distributions as well.

For that the following two files from a base SLE system are needed:

  • /etc/SUSEConnect for the API access point
  • /etc/zypp/credentials.d/SCCcredentials for providing the user credentials

These files can be copied from a SLE machine that has been successfully registered at the SUSE Customer Center, RMT or SMT.

A Docker version of 18.09 or above is needed to provide a secure way to mount the credentials into the image build process.

A Dockerfile for building a SLE15 image which contains go would then look as follows:

# syntax=docker/dockerfile:1.0.0-experimental
FROM registry.suse.com/suse/sle15:latest

ARG ADDITIONAL_MODULES
RUN --mount=type=secret,id=SUSEConnect,required \
    --mount=type=secret,id=SCCcredentials,required \
    zypper -n --gpg-auto-import-keys in go

This file mounts all necessary secrets into the image during the build process and removes it afterwards. Please note that the first line of the Dockerfile is mandatory at the time of writing. Both files SUSEConnect and SCCcredentials needs to be available beside the Dockerfile.

After creating the file you can build the image by executing:

docker build -t sle15-go \
    --build-arg ADDITIONAL_MODULES=sle-module-development-tools \
    --secret id=SUSEConnect,src=SUSEConnect \
    --secret id=SCCcredentials,src=SCCcredentials \
    .

At the time of writing (docker 18.09.0) it is necessary to enable the Docker BuildKit by setting the environment variable DOCKER_BUILDKIT. The ADDITIONAL_MODULES are used here to enable all needed repositories. After the image has been built the package should be usable within the docker image:

docker run sle15-go go version
go version go1.9.7 linux/amd64

Please keep in mind that it is not possible to use container-suseconnect or zypper within the container after the build, because the secrets are not available any more.

Alternative approach when using podman as the container runtime

When using podman as the container runtime, add the following to /etc/containers/mounts.conf (when building containers as root) or ~/.config/containers/mounts.conf (when building containers as a regular user):

<path_on_host>/SUSEConnect:/etc/SUSEConnect
<path_on_host>/SCCcredentials:/etc/zypp/credentials.d/SCCcredentials

No further change are needed in Dockerfile.

Obtaining the SUSEConnect and SCCcredentials secrets

Ideally the host system on which the container builds are executed is registered. The credentials stored on the host system in /etc/zypp/credentials.d/SCCcredentials can be used to register containers running or building on that host as well.

Otherwise start the container that should be registered and execute SUSEConnect inside it:

SUSEConnect -e <youremailaddress> -r <yourregistrationcode>

In case you have a registration code that hasn't otherwise be used, you can use the USERNAME "regcode" and the given registration code as password.

For interactive use of containers you can also pass the obtained username and password via environment variables

docker run -e SCC_CREDENTIAL_USERNAME=<credential_username> \
    -e SCC_CREDENTIAL_PASSWORD=<credential_password> \
    my-image

# License

Licensed under the Apache License, Version 2.0. See
[LICENSE](./LICENSE) for the full license text.

container-suseconnect's People

Contributors

codelingoteam avatar dcermak avatar dependabot[bot] avatar dirkmueller avatar dmacvicar avatar fcrozat avatar flavio avatar jvanz avatar mssola avatar mwilck avatar rhafer avatar saschagrunert avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

container-suseconnect's Issues

Licensing requirements?

SLES is typically licensed per physical host/cpu or virtual machines? When we build or run SLES containers - what kind of licensing do we need? I already tried to get this information multiple times from SUSE and Rancher but never got a feedback that we could work with.

I guess the simple situation is when we build and run SLES containers on SLES hosts. But what kind of subscriptions do we need when we create or run such containers on non-SLES hosts? For example developer workstations running Windows or cloud container platforms. Do we just need one licensed SLES X machine to build and run an unlimited number of SLES X containers?

Using the registered zypper repositories from the host system - does this have any side effects if this machine is connected to SUSE Manager or Uyuni? Building a container image downloads packages that are not installed on the host which is registered to the repositories. What if we build containers with packages from different products like the HA extensions?

Add parsing of *.prod files

The idea is to parse the module names from the *.prod files within /etc/products.d/, like these:

sle-module-basesystem.prod
sle-module-containers.prod
sle-module-live-patching.prod
sle-module-server-applications.prod

This would allow building images with kiwi without setting the ADDITIONAL_MODULES environment variable.

Extending containers without docker and SLE

The README.md explains how to extend SLE containers on non-SLE systems using docker. I was wondering if it also works with podman and buildah. The answer is yes, even though buildah bud doesn't support DOCKER_BUILDKIT and RUN --mount type=secret.

Instead, it can be done with buildah as follows. Like with docker, valid SUSEConnect and SCCcredentials files are required and must be accessible locally.

#! /bin/bash
NAME=my-sle15-container
BASE="registry.suse.com/suse/sle15:15.2"
# list of packages to install
PACKAGES="make gcc"
# List of addon modules to activate
ADDONS="sle-module-development-tools,PackageHub"
WORK=$(buildah from "$BASE")
echo working on "$WORK" >&2
buildah config --env "ADDITIONAL_MODULES=$ADDONS" "$WORK"
buildah  run --mount=type=bind,src=$PWD/SUSEConnect,dst=/run/secrets/SUSEConnect \
	 --mount=type=bind,src=$PWD/SCCcredentials,dst=/run/secrets/SCCcredentials \
	 "$WORK" \
	 zypper -n --gpg-auto-import-keys \
	 install $PACKAGES
buildah run "$WORK" zypper clean --all
# make sure ADDITIONAL_MODULES isn't set in the built container
buildah config --env "ADDITIONAL_MODULES-" "$WORK"
buildah commit "$WORK" "$NAME"

Unlike docker build, it's actually possible to remove the -n flag from the zypper command line and thus solve possible conflicts during the build.

Perhaps you want to add that to the README?

container-suseconnect doesn't do any caching of registration

When running SLE Base Image (15 SP3) on a SLES host:

each zypper call results to a container-suseconnect call to "register" the container against SCC. This takes usually between 15 to 20s.
This call is not cached at all, even if the repositories were properly added to the container.

For instance, starting from new container:

  • zypper lr => wait 20s
  • all SLE 15 SP3 repositories are properly added to the container
  • zypper in iptables
  • container-suseconnect is called again and spend 20s to re-register the container (while it is still registered)
  • then packages are downloaded and installed.

It seems there is no caching of registration, unlike on a regular SLE system.

Those delays are not visible at all when container-suseconnect is disabled, which is bad as user experience for our customers.

Kubernetes/Rancher integration

Hello,

this is probably a bigger idea - it would be nice if there was an option to have Kubernetes containers in a Kubernetes/Rancher cluster (of course run on top of SLES or SLE Micro hosts) automatically licensed - possibly through some Rancher option or Kubernetes configmap to automatically attach the necessary volume mounts?

Again, I understand it's more than a bug, maybe it could be taken up as a feature request for the future! :-)

Best,
Georg

Building SLES 12SP5 Docker images in Google Compute Engine

I am using a combination of Creating a Custom SLE 12 Image and Example Dockerfiles to build a SLES 12SP5 Docker image using a Google Compute Engine (GCE) on-demand VM (image is sles-12-sp5-v20200610).

The Dockefile is

FROM registry.suse.com/suse/sles12sp5:latest

# Import the crt file of our private SMT server
ADD http://smt-gce/smt.crt /etc/pki/trust/anchors/smt.crt
RUN update-ca-certificates

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in vim

which I am building with

docker build --network host --tag custum-sles12sp5:latest .

but it is failing with the following error

Step 4/5 : RUN zypper --gpg-auto-import-keys ref -s
 ---> Running in 4b9177892812
Refreshing service 'container-suseconnect-zypp'.
Adding repository 'SLES12-SP5-Debuginfo-Pool for sle-12-x86_64' [......done]
Adding repository 'SLES12-SP5-Debuginfo-Updates for sle-12-x86_64' [......done]
Adding repository 'SLES12-SP5-Installer-Updates for sle-12-x86_64' [......done]
Adding repository 'SLES12-SP5-Pool for sle-12-x86_64' [......done]
Adding repository 'SLES12-SP5-Source-Pool for sle-12-x86_64' [......done]
Adding repository 'SLES12-SP5-Updates for sle-12-x86_64' [......done]
All services have been refreshed.
Retrieving repository 'SLES12-SP5-Pool for sle-12-x86_64' metadata [.
Medium not attached: plugin:/susecloud?credentials=&path=/repo/SUSE/Products/SLE-SERVER/12-SP5/x86_64/product/

The digest of the base Docker image (registry.suse.com/suse/sles12sp5:latest) is sha256:2e6da53d3dba5c5eec8d7b5e81d4c920fec52b10bddb167bc6f4f3191e28f08e

Following Building images on-demand SLE instances in the public cloud, when I start the containerbuild-regionsrv service I get the following error:

$ sudo systemctl start containerbuild-regionsrv
Failed to start containerbuild-regionsrv.service: Unit containerbuild-regionsrv.service failed to load: No such file or directory.

Questions

  1. Is there a newer GCE VM image I should be using when building Docker images?
  2. Is there a newer Docker image that I should be using in my FROM statement?
  3. Is there a way to install the susecloud plugin in the image I am building?

Problem retrieving the repository index file

I am running SLES 12SP4 in VM on Google Compute Engine (GCE) and following the documentation for Creating Custom Images. When I try to build the following Dockerfile

FROM registry.suse.com/suse/sles12sp4:latest

RUN zypper ref -s
RUN zypper -n in vim

I get the following error:

Problem retrieving the repository index file for service 'container-suseconnect-zypp':
[container-suseconnect-zypp|file:/usr/lib/zypp/plugins/services/container-suseconnect-zypp]

and see the following in the log file:

2019/10/29 03:07:27 Installed product: SLES-12.4-x86_64
2019/10/29 03:07:27 Warning: Unknown key 'language'
2019/10/29 03:07:27 Registration server set to https://smt-gce.susecloud.net
2019/10/29 03:07:27 Unexpected error while retrieving products with regCode : 401 Unauthorized
2019/10/29 03:07:27 Unexpected error while retrieving products with regCode : 401 Unauthorized

This error message is coming from products.go which is attempting to make an HTTP GET to /connect/subscriptions/products without an authorization token (c.f., the comment about SMT does not need regcode). However, accoding the to the v4 API docs it is confusing about whether a token is needed:

all endpoints on this level of the subscription's token (registration code) is used for authentication. This should be sent as an authorization header

but further down it says:

A registration code is not required for authentication by RMT or SMT

If I use curl to make the equivalent call

$ curl -X GET "https://smt-gce.susecloud.net/connect/subscriptions/products?identifier=SLES&version=12&arch=x86_64" -H "accept: application/json"
HTTP Token: Access denied.

I decided to try re-building container-suseconnect with the following changes:

  1. Change URL path from /connect/subscriptions/products to /connect/systems/products in products.go
  2. Include basic auth credentials for the HTTP GET to /connect/subscriptions/products in products.go

I then had to change the return type for the following functions from []Product to Product

  1. parseProducts
  2. requestProductsFromRegCode

After replacing /usr/lib/zypp/plugins/services/container-suseconnect-zypp with my modified binary, I was able to run zypper ref -s and zypper in -n vim inside of a container although I was prompted for my basic auth credentials twice.

Zypper got HTTP 401 on refresh with SLES15SP1 on GCE in docker

Environment:

  • Host version is SLES15SP1
  • Cloud environment Google Cloud Engine
  • SMT server has been presented by Google or Suse may be, not sure, but I have no control.
  • Special GCE trouble: smt-gce.susecloud.net is not resolved from GCE network, so every host has entry in /etc/hosts.
  • There is a trouble with x509, which force me to import cert from SMT server.

Reproduce steps:

  • Create host on GCE with SLES 15 SP 1 official image.
  • Ensure zypper is OK on host
  • Install and enable docker.
  • Prepare following Dockerfile:
FROM registry.suse.com/suse/sle15:latest

ENV ADDITIONAL_MODULES sle-module-desktop-applications,sle-module-development-tools

ADD http://smt-gce.susecloud.net/smt.crt /etc/pki/trust/anchors/smt.crt
RUN update-ca-certificates
RUN container-suseconnect

RUN zypper --gpg-auto-import-keys ref -s
RUN zypper -n in gvim
  • Build docker. (Take a note about addition /etc/hosts entry about smt server)
docker build -t test1  --add-host="smt-gce.susecloud.net:192.158.29.172"  .

Expected

Docker build success.

Actual

# docker build -t test1 \
> --add-host="smt-gce.susecloud.net:192.158.29.172" \
> .
Sending build context to Docker daemon  14.85kB
Step 1/7 : FROM registry.suse.com/suse/sle15:latest
 ---> 91f2bad53a20
Step 2/7 : ENV ADDITIONAL_MODULES sle-module-desktop-applications,sle-module-development-tools
 ---> Using cache
 ---> 4fd55addbbcb
Step 3/7 : ADD http://smt-gce.susecloud.net/smt.crt /etc/pki/trust/anchors/smt.crt
Downloading [==================================================>]  1.891kB/1.891kB
 ---> Using cache
 ---> 293e850276b3
Step 4/7 : RUN update-ca-certificates
 ---> Using cache
 ---> 50c9c64805e1
Step 5/7 : RUN container-suseconnect
 ---> Using cache
 ---> 91263b5080c8
Step 6/7 : RUN zypper --gpg-auto-import-keys ref -s
 ---> Running in 341a38f50f23
Refreshing service 'container-suseconnect-zypp'.
Adding repository 'SLE-Module-Basesystem15-SP1-Debuginfo-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Basesystem15-SP1-Debuginfo-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Basesystem15-SP1-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Basesystem15-SP1-Source-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Basesystem15-SP1-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Desktop-Applications15-SP1-Debuginfo-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Desktop-Applications15-SP1-Debuginfo-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Desktop-Applications15-SP1-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Desktop-Applications15-SP1-Source-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Desktop-Applications15-SP1-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-DevTools15-SP1-Debuginfo-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-DevTools15-SP1-Debuginfo-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-DevTools15-SP1-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-DevTools15-SP1-Source-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-DevTools15-SP1-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Server-Applications15-SP1-Debuginfo-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Server-Applications15-SP1-Debuginfo-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Server-Applications15-SP1-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Server-Applications15-SP1-Source-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Module-Server-Applications15-SP1-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Product-SLES15-SP1-Debuginfo-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Product-SLES15-SP1-Debuginfo-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE-Product-SLES15-SP1-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Product-SLES15-SP1-Source-Pool for sle-15-x86_64' [......done]
Adding repository 'SLE-Product-SLES15-SP1-Updates for sle-15-x86_64' [......done]
Adding repository 'SLE15-SP1-Installer-Updates for sle-15-x86_64' [......done]

All services have been refreshed.
Retrieving repository 'SLE-Module-Basesystem15-SP1-Pool for sle-15-x86_64' metadata [.
Authentication required for 'https://smt-gce.susecloud.net/repo/SUSE/Products/SLE-Module-Basesystem/15-SP1/x86_64/product/'
User Name: Authentication required for 'https://smt-gce.susecloud.net/repo/SUSE/Products/SLE-Module-Basesystem/15-SP1/x86_64/product/'
User Name: error]
Repository 'SLE-Module-Basesystem15-SP1-Pool for sle-15-x86_64' is invalid.
[container-suseconnect-zypp:SLE-Module-Basesystem15-SP1-Pool|https://smt-gce.susecloud.net/repo/SUSE/Products/SLE-Module-Basesystem/15-SP1/x86_64/product/] Valid metadata not found at specified URL
History:
 - [|] Error trying to read from 'https://smt-gce.susecloud.net/repo/SUSE/Products/SLE-Module-Basesystem/15-SP1/x86_64/product/'
 - Login failed. (https://smt-gce.susecloud.net/repo/SUSE/Products/SLE-Module-Basesystem/15-SP1/x86_64/product/content): The requested URL returned error: 401 Unauthorized
.....

"Building images on non SLE distributions" doesn't work for SLE12-SP3

Building SLE12-SP3 containers according to the docs fails. Sample Dockerfile:

# syntax = docker/dockerfile:experimental
FROM registry.suse.com/suse/sles12sp3
ARG ADDITIONAL_MODULES=

RUN --mount=type=secret,id=SUSEConnect,required \
    --mount=type=secret,id=SCCcredentials,required \
     zypper -n --gpg-auto-import-keys \
     install less

Trying to build this:

sle12-sp3> docker build -t sle12-sp3-test \
		--secret id=SUSEConnect,src=SUSEConnect \
		--secret id=SCCcredentials,src=SCCcredentials \
...	
#7 [2/2] RUN --mount=type=secret,id=SUSEConnect,required   --mount=type=secret,id=SCCcredentials,required      zypper -n --gpg-auto-import-keys      install less:
#7 1.934 Refreshing service 'container-suseconnect'.
#7 2.517 Problem retrieving the repository index file for service 'container-suseconnect':
#7 2.517 [container-suseconnect|file:/usr/lib/zypp/plugins/services/container-suseconnect] 
#7 2.517 Warning: Skipping service 'container-suseconnect' because of the above error.
#7 2.517 Loading repository data...
#7 2.517 Warning: No repositories defined. Operating only with the installed resolvables. Nothing can be installed.
#7 2.518 Reading installed packages...
#7 2.523 No provider of 'less' found.
#7 2.523 'less' not found in package names. Trying capabilities.
------
failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = failed to build LLB: executor failed running [/bin/sh -c zypper -n --gpg-auto-import-keys      install less]: docker-runc did not terminate sucessfully

For SLE12-SP4 (just replacing the image in the FROM line), this works fine, with the same credentials. I also verified that my credentials do work for SLE12-SP3. The problem is that refreshing container-suseconnect service failed, and thus no repositories are defined.

Un-necessary warning: Problem retrieving the repository index file for service 'container-suseconnect-zypp'

Dockerfile with
RUN zypper in -y <pkg>
errors with:

Problem retrieving the repository index file for service 'container-suseconnect-zypp':
[container-suseconnect-zypp|file:/usr/lib/zypp/plugins/services/container-suseconnect-zypp]
Warning: Skipping service 'container-suseconnect-zypp' because of the above error.

Then the package will be installed.

Is it possible to get rid of the un-necessary warning message?

Find solution for needed regcode parsing

The following code part decides whether a registration code retrieval is needed or not:

if data.SccURL == sccURLStr {
regCodes, err = requestRegcodes(data, credentials)
if err != nil {
return products, err
}
} else {
// SMT does not have this API and does not need a regcode
regCodes = append(regCodes, "")
}

This is currently a bit unflexible and proxies for the server https://scc.suse.com won't work any more since it will be assumed that no registration code is needed. A solution would be to make it configurable, but it has to be evaluated how and where.

Building images with container-suseconnect takes way too long...

Hi, I noticed that building images with container-suseconnect can take a very long time

Example:

  • Dockerfile:
# syntax=docker/dockerfile:experimental
FROM registry.suse.com/suse/sle15:latest

ENV ADDITIONAL_MODULES sle-module-basesystem,sle-module-development-tools

RUN --mount=type=secret,id=SCCcredentials,required \
    zypper --non-interactive up && \
    zypper --non-interactive in git
  • Build command:
    DOCKER_BUILDKIT=1 docker image build --pull --secret id=SCCcredentials,src=SCCcredentials -t reg-build . (already had credentials pulled)

[+] Building 3386.3s (4/6)
[+] Building 3386.5s (4/6)
[+] Building 338[+] Building 4206.6s (4/6)
[+] Building 4551.4s (5/6)

In this particular case the build failed because I had not add the sle-development-tools module, but still took about an hour to do so, spending most of it to build and add repos...

5 4550.9 No provider of 'git' found.

Thank you!

x509 issue when creating SLES12SP4 Container Image

We experienced x509 certificate issue on the SLES12SP4 docker container, with 2.0.0 release of the container-suseconnect.

$ update-ca-certificates 
$ container-suseconnect 
2019/10/23 18:07:59 Installed product: SLES-12.4-x86_64
2019/10/23 18:07:59 Registration server set to https://smt-gce.susecloud.net
2019/10/23 18:07:59 Get https://smt-gce.susecloud.net/connect/subscriptions/products?arch=x86_64&identifier=SLES&version=12.4: x509: issuer name does not match subject from issuing certificate

$ container-suseconnect --version
container-suseconnect version 2.0.0

However, when we use openssl, there is no trouble connecting to the smt:

$ openssl s_client -connect smt-gce.susecloud.net:443

We are not sure whether this is related to #19.

For additional details, please check the thread at https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/gce-discussion/9H06B-WZ1VA/yuy2RLAdDAAJ

How to choose IPv6 vs. IPv4?

When trying to debug some difficulties with container-suseconnect-zypp I've noticed that during podman build (i.e., when invoked with RUN) it seems to use IPv6 and fail, whereas during podman run (i.e., invoked with CMD) it seems to use IPv4 and succeed.

I don't think that the distinction between IPv6 and IPv4 is actually the problem, since when I build with --network=host I still see container-suseconnect-zypp use IPv6, but it actually succeeds; however, it would be nice to be able to explicitly set the IP version to help further document this behavior for another GH issue.

Is there a way to explicitly set IPv6 or IPv4 for troubleshooting?

Please adapt Readme: Remove section about usage of credentials on non SLE distros

This section in the README is misleading as you can access the BCI Repo without any credentials:

Building images on non SLE distributions

It is possible to build SLE based docker images on other distributions as well. For that the following two files from a base SLE system are needed:

/etc/SUSEConnect for the API access point
/etc/zypp/credentials.d/SCCcredentials for providing the user credentials
These files can be copied from a SLE machine that has been successfully registered at the SUSE Customer Center, RMT or SMT.

With Ubuntu 20.04 I was able to build it without any restrictions:

root@ubuntu:~# cat docker_test

syntax=docker/dockerfile:1.0.0-experimental

FROM registry.suse.com/suse/sle15:latest

ARG ADDITIONAL_MODULES
RUN zypper -n --gpg-auto-import-keys in go postfix

root@ubuntu:~# docker build -t mysle15sp3:v1 --progress=plain -f docker_test .
Sending build context to Docker daemon 288.3kB
Step 1/3 : FROM registry.suse.com/suse/sle15:latest
latest: Pulling from suse/sle15
a8e7a8d5a3ff: Pull complete
Digest: sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5
Status: Downloaded newer image for registry.suse.com/suse/sle15:latest
---> d2fc302527bc
Step 2/3 : ARG ADDITIONAL_MODULES
---> Running in 22be69133481
Removing intermediate container 22be69133481
---> 3481210baa95
Step 3/3 : RUN zypper -n --gpg-auto-import-keys in go postfix
---> Running in 6b88908db7f6
Refreshing service 'container-suseconnect-zypp'.
Problem retrieving the repository index file for service 'container-suseconnect-zypp':
[container-suseconnect-zypp|file:/usr/lib/zypp/plugins/services/container-suseconnect-zypp]
Warning: Skipping service 'container-suseconnect-zypp' because of the above error.
Building repository 'SLE_BCI' cache [....done]
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 37 NEW packages are going to be installed:
binutils cpp cpp7 gcc gcc7 glibc-devel go go1.17 iproute2 libasan4 libatomic1 libcilkrts5 libctf-nobfd0 libctf0 libgomp1 libicu-suse65_1 libicu65_1-ledata libisl15 libitm1 liblmdb-0_9_17 liblsan0 libmnl0 libmpc3 libmpfr6 libmpx2 libmpxwrappers2 libtsan0 libubsan0 libxcrypt-devel libxtables12 linux-glibc-devel pkg-config postfix system-user-mail system-user-nobody timezone update-alternatives
.......

root@ubuntu:~# docker image list
REPOSITORY TAG IMAGE ID CREATED SIZE
mysle15sp3 v1 d26c5594432d 17 minutes ago 1GB
registry.suse.com/suse/sle15 latest d2fc302527bc 29 hours ago 116MB

Doesn't work with our subscription / if several regcodes are returned, some of them expired

requestRegcodes() adds all the subscriptions found to the slice. In our case the GET request returns two subscriptions, one with an expired regcode, the second with the current, active one.
RequestProducts() then bails on any error returned. Of course there is a 401 returned for the expired regcode.
Two ways to fix this:

  • Filter expired regcodes in requestRegcodes()
  • Don't bail / return an error if at least one of the regcodes worked to return some products

Probably both should be implemented. If at least one of the regcodes worked there is no need to break the entire operation.
We currently cannot use SLES containers because of this issue. I'm going to fix this locally (probably by just ignoring the error in RequestProducts()).

Logging behavior

Currently, if container-suseconnect is loaded as a Zypper plugin, it only writes logs to a file by default.

libzypp will propagate any stderr messages if the plugin exists with a non-zero code. In this case, the error should be visible in the application's log (zypper, YAST, PK, etc.).

If the host system license is invalid or expired, container-suseconnect will silently fail (only writing to a log file) while zypper will continue to work without any repositories and possibly fail to install packages that are only available to registered systems.

What I'm not sure is if zypper execution will be aborted if a plugin fails, or if it continues to work. Ideally, zypper should still continue as not all zypper calls require a valid credential.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.