Container Guide

SUSE Linux Enterprise Server 15 SP2

Container GuideSUSE Linux Enterprise Server 15 SP2

This document is a work in progress. The content in this document is subject tochange without notice.

Publication Date: October 16, 2020

SUSE LLC1800 South Novell PlaceProvo, UT 84606USA

https://documentation.suse.com

Copyright © 2006– 2020 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free

Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this

copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU

Free Documentation License”.

For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the

property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its

affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does

not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be

held liable for possible errors or the consequences thereof.

Contents

About This Guide v

1 Introduction 11.1 Terminology 1

2 Building Containers 2

2.1 Build Tools Available to Customers 2

Docker 2 • Podman 2 • Buildah 3

2.2 Internal SUSE Build Tools 3

Open Build Service 3 • KIWI 3

2.3 Building Ocial SLE Images 4

3 Obtaining Containers 5

3.1 SUSE Linux Enterprise Base Images 5

3.2 SUSE Container Properties 5

Repository Names 5 • Labels 6 • Tags 8

3.3 SUSE Registry 9

3.4 Comparing Containers 9

3.5 On-Premises Registry 10

Portus 10

4 Support Plans 11

4.1 Supported Containers on SUSE Host Environments 11

Tier One 11 • Tier Two 11 • Tier Three 12

4.2 Supported Container Host Environments 12

Tier One 12 • Tier Two 12 • Tier Three 13 • Tier Four 13

iii Container Guide

A GNU Licenses 14

A.1 GNU Free Documentation License 14

iv Container Guide

About This Guide

This guide provides an introduction to the SUSE container ecosystem.

1 Required BackgroundTo keep the scope of these guidelines manageable, certain technical assumptions have beenmade:

You have some computer experience and are familiar with common technical terms.

You are familiar with the documentation for your system and the network on which it runs.

You have a basic understanding of Linux systems.

2 Giving FeedbackYour feedback and contributions to this documentation are welcome! Several channels are avail-able:

Service Requests and Support

For services and support options available for your product, refer to https://www.suse.com/

support/ .To open a service request, you need a subscription at SUSE Customer Center. Go to https://

scc.suse.com/support/requests , log in, and click Create New.

Bug Reports

Report issues with the documentation at https://bugzilla.suse.com/ . To simplify thisprocess, you can use the Report Documentation Bug links next to headlines in the HTML ver-sion of this document. These preselect the right product and category in Bugzilla and adda link to the current section. You can start typing your bug report right away. A Bugzillaaccount is required.

Contributions

To contribute to this documentation, use the Edit Source links next to headlines in theHTML version of this document. They take you to the source code on GitHub, where youcan open a pull request. A GitHub account is required.

v Required Background SLES 15 SP2

For more information about the documentation environment used for this doc-umentation, see the repository's README (https://github.com/SUSE/doc-sle/blob/mas-

ter/README.adoc) .

Mail

Alternatively, you can report errors and send feedback concerning the documentation todoc-team@suse.com . Make sure to include the document title, the product version andthe publication date of the documentation. Refer to the relevant section number and title(or include the URL) and provide a concise description of the problem.

3 Documentation ConventionsThe following notices and typographical conventions are used in this documentation:

/etc/passwd : directory names and le names

PLACEHOLDER : replace PLACEHOLDER with the actual value

PATH : the environment variable PATH

ls , --help : commands, options, and parameters

user : users or groups

package name : name of a package

Alt , Alt – F1 : a key to press or a key combination; keys are shown in uppercase as ona keyboard

File, File Save As: menu items, buttons

AMD/Intel This paragraph is only relevant for the AMD64/Intel 64 architecture. The ar-rows mark the beginning and the end of the text block. IBM Z, POWER This paragraph is only relevant for the architectures IBM Z and POWER .

The arrows mark the beginning and the end of the text block.

Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter inanother manual.

Commands that must be run with root privileges. Often you can also prefix these com-mands with the sudo command to run them as non-privileged user.

vi Documentation Conventions SLES 15 SP2

root # commandtux > sudo command

Commands that can be run by non-privileged users.

tux > command

Notices

Warning: Warning NoticeVital information you must be aware of before proceeding. Warns you about securityissues, potential loss of data, damage to hardware, or physical hazards.

Important: Important NoticeImportant information you should be aware of before proceeding.

Note: Note NoticeAdditional information, for example about differences in software versions.

Tip: Tip NoticeHelpful information, like a guideline or a piece of practical advice.

vii Documentation Conventions SLES 15 SP2

1 Introduction

1.1 Terminology

Container

A container is a standard unit of software that packages up code and all its dependencies.This allows the container and its application to run quickly and reliably in various comput-ing environments. Containers can include all the components required for an application torun. Multiple containers can run on a single host operating system instance, but each con-tainer is isolated from other containers. From the perspective of a program in a container,it is the only thing running on the host OS. Unlike a virtual machine, a container does nothave its own kernel. All containers on an OS instance share the kernel of the host OS.

Container Image

A container image is an unchangeable, static le that includes executable code so it can runan isolated process on IT infrastructure. The image is comprised of system libraries, systemtools, and other platform settings a program needs to run on a containerization platform. Acontainer image is compiled from le system layers built on top of a parent or base image.

Base Image

A base image is an minimal initial image. In a Dockerfile, a base image is identified bythe FROM scratch directive.

Parent Image

The image that served the basis for another container image. In other words, if an imageis not a base image, it is derived from a parent image. In a Dockerfile, the FROM directiveis pointing to the parent image. Most Docker containers are created using parent images.

Container Orchestration

Orchestration is the automatic process of deploying, managing, scaling and schedulingthe work of individual containers within multiple clusters. Orchestration is done using adedicated tool like Kubernetes (https://kubernetes.io/) .

Container Platform

SUSE CaaS Platform is a container platform.

1 Terminology SLES 15 SP2

2 Building Containers

This chapter provides an overview of tools for creating containers. Most of the tools men-tioned below are part of the SUSE Linux Enterprise Server 15 SP2 Containers Mod-ule. You can see the full list of packages in the Containers Module in the SUSE Cus-

tomer Center (https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&ver-

sion=15.2&arch=x86_64&query=&module=1963) .

2.1 Build Tools Available to Customers

2.1.1 Docker

Docker is a system for creating and managing containers. Its core is the Docker Open SourceEngine—a lightweight virtualization solution to run containers simultaneously on a single host.Docker containers are defined using Dockerfiles. A Dockerfile describes how to assemble a pri-vate filesystem for a container. The le can also contain metadata that describes how to runthe container. Most Dockerfiles start from a parent image. For an introduction on how to createcustom base SUSE Linux Enterprise Docker images, see Book “Docker Open Source Engine Guide”.

2.1.2 Podman

Podman is short for Pod Manager tool, and its purpose extends beyond just building images.It is a daemonless container engine for developing, managing, and running Open ContainersInitiative (OCI) containers on a Linux system, and it offers a drop-in alternative for Docker.Podman is the default container runtime in openSUSE Kubic—a certified Kubernetes distributionbuilt on top of openSUSE. Podman can be used to create OCI-compliant container images usinga Dockerfile and a range of commands similar to Docker. For example, the podman buildcommand performs the same task as docker build , except that it does not use the Dockerdaemon to do it. Another important feature of Podman are rootless container builds. BecausePodman relies on user namespaces, which provide an isolation mechanism for Linux processes,it does not require root privileges to create and run containers.

For instructions on how to install and use Podman see the Podman Documentation (https://pod-

man.io/) .

2 Build Tools Available to Customers SLES 15 SP2

2.1.3 Buildah

Buildah facilitates building OCI container images. It is a complimentary tool to Podman (seeSection 2.1.2, “Podman”), and podman build uses Buildah to perform container image builds.Buildah makes it possible to build images from scratch, from existing images, and using Dock-erfiles. OCI images built using the Buildah command-line tool and the underlying OCI-basedtechnologies (for example, containers/image and containers/storage ) are portable andcan therefore run in a Docker environment.

For instructions on how to install and use Buildah, see the Buildah Documentation (https://buil-

dah.io/) and tutorials (https://github.com/containers/buildah/blob/master/docs/tutorials) .

2.2 Internal SUSE Build Tools

2.2.1 Open Build Service

The Open Build Service (OBS) provides free infrastructure for building and storing RPM pack-ages including various container formats. The OBS Container Registry (https://registry.open-

suse.org/cgi-bin/cooverview) provides a detailed listing of all container images built by theOBS, complete with commands for pulling the images into your local Docker environment. TheOBS openSUSE container image templates (https://build.opensuse.org/image_templates) can bemodified to specific needs, which offers the easiest way to create your own container branch.Container images can be built with native Docker tools from an existing image using a Docker-file. Alternatively, images can be built from scratch using the KIWI image-building solution.

Instructions on how to build images on OBS can be found at https://openbuildser-

vice.org/2018/05/09/container-building-and-distribution/ .

2.2.2 KIWI

KIWI Next Generation is a multi-purpose tool for building images. In addition to container im-ages, regular installation ISO images, and images for virtual machines, KIWI can build imagesthat boot via PXE or Vagrant boxes. The main building block in KIWI is an image XML descrip-tion, a directory that includes the config.xml or .kiwi le along with scripts or configurationdata. The process of creating images with KIWI is fully automated and does not require any

3 Buildah SLES 15 SP2

user interaction. Any information required for the image creation process is provided by theprimary configuration le config.xml . The image can be customized using the config.shand images.sh scripts.

NoteIt is important to distinguish between KIWI NG (currently version 9.20.9) and its un-maintained legacy versions (7.x.x or older), now called KIWI Legacy (https://documenta-

tion.suse.com/kiwi/) .

For specific information on how to install KIWI and use it to build images, see the KIWI docu-

mentation (http://osinside.github.io/kiwi/) . A collection of example image descriptions can befound on the KIWI GitHub repository (https://github.com/OSInside/kiwi-descriptions) .

KIWI's man pages provide information on using the tool. To access man pages, install the ki-wi-man-pages package.

2.3 Building Ocial SLE ImagesImages are considered official only if they are built using the Internal Build Service.

There are no official SLE container images on https://build.opensuse.org , and the RPMs ex-ported there are not identical to the internal ones. This means that it is not possible to buildofficially supported images on https://build.opensuse.org .

4 Building Official SLE Images SLES 15 SP2

3 Obtaining Containers

This chapter provides information on obtaining container images.

3.1 SUSE Linux Enterprise Base ImagesSUSE offers a large number of official base container images that can be used as a starting pointfor building custom containers. Each SLE base image contains a SLE release without the kernel.The OS included in the base image is an empty environment without any functionality.

Base images are available from https://registry.suse.com . For information about the SUSE Reg-istry, see Section 3.3, “SUSE Registry”. The images in the SUSE Registry are all Generally Availabili-ty (Production) and LTSS (https://www.suse.com/products/long-term-service-pack-support/) re-leases of SLES 12 and SLES 15. SUSE Linux Enterprise base images in the SUSE Registry receivesecurity updates and covered by the SUSE support plans. For more information about thesesupport plans, see Chapter 4, Support Plans.

3.2 SUSE Container PropertiesSUSE container images have identifiers that help you choose the right image for your needs.The individual identifiers listed below can be accessed after you pull a container image fromthe repository and run podman inspect on it.

3.2.1 Repository Names

Repository names start with the name of the product, for example: suse/sle/(…) , open-suse/tumbleweed/(…) , caasp/(…) . The SLE 15 containers for all service packs reside in thenamespace suse/sle15 . This applies to future versions of SLE as well (for example, suse/sle16 ). However, for SLE 12, there is a separate repository name for each service pack, forexample suse/sle12sp3 , suse/sle12sp4 , suse/sle12sp5 .

5 SUSE Linux Enterprise Base Images SLES 15 SP2

3.2.2 Labels

Labels help to identify images. All SLE container image labels begin with com.suse.<produc-t>.<containername> after which follows a further specification. openSUSE container imagesare identified by a label that begins with org.opencontainers .

Important: The com.suse.sle.base label is protected.With every layer added to a base image, the labels defined in the base container areoverwritten by labels in the derived image. To protect information about the origin of theimage, the label com.suse.sle.base has been added to SLE container images. This labelindicates that SUSE is the vendor of the image in question. Since the label is protected,it is not overwritten by any modifications made to the base image.

The opposite is true for openSUSE base images, where labels are not protected. For ex-ample, org.opencontainers.image.title always contains the title of the layer addedlast.

A list of all currently defined labels follows:

TABLE 3.1: CURRENTLY DEFINED LABELS

Must be provid-ed by derivedimages

Labels OCI Annotation Description Example

Yes org.opencontain-ers.image.titlecom.suse.sle.base.ti-tle

org.opencontain-ers.image.title

Title of the im-age

SUSE Linux En-terprise 15 BaseContainer

Yes org.opencon-tainers.im-age.descriptioncom.suse.sle.base.de-scription

org.opencontain-ers.image.de-scription

Short descrip-tion of the im-age

Image contain-ing a minimalenvironment forcontainers basedon SUSE LinuxEnterprise 15.

6 Labels SLES 15 SP2

Must be provid-ed by derivedimages

Labels OCI Annotation Description Example

Yes org.opencon-tainers.im-age.versioncom.suse.sle.base.ver-sion

org.opencontain-ers.image.ver-sion

Image version <code-stream>.<sp>.<ci-cnt>.<bldcnt>15.0.4.2

Yes org.opencon-tainers.im-age.createdcom.suse.sle.base.cre-ated

org.opencontain-ers.image.creat-ed

Timestamp ofimage build

2018-07-27T14:12:30Z

No org.opencon-tainers.im-age.vendorcom.suse.sle.base.ven-dor

org.opencontain-ers.image.ven-dor

Image vendor SUSE LLC

No org.opencontain-ers.image.urlcom.suse.sle.base.url

org.opencontain-ers.image.url

Further informa-tion

https://

www.suse.com/

products/serv-

er/

Yes org.openbuild-service.disturlcom.suse.sle.base.dis-turl

org.openbuild-service.disturl

Image OBS URL obs://build.suse.de/SUSE:SLE-15:Up-date:CR/im-ages/2951b67133d-d6384cacb28203174e030-sles15-image

7 Labels SLES 15 SP2

Must be provid-ed by derivedimages

Labels OCI Annotation Description Example

Yes org.open-suse.referencecom.suse.sle.base.ref-erence

org.opensuse.ref-erence

Reference point-ing to this spe-cific image.The image youget with dock-er pull <re-f.name> mustnot change.

reg-istry.suse.com/suse/sle15:4.2

3.2.3 Tags

Tags are used for adding clarifying information. Unlike labels, tags can be freely defined. Tagsusually contain information about the specific version of the container image.

If a tag exists in multiple images, the newest image is used. The image maintainer decides whichtags to assign to the container image.

The conventional tag format is repository name : image version specification (usuallyversion number). For example, the tag for the latest published image of SUSE Linux EnterpriseServer 15 SP1 would be suse/sle15:15.1 .

The following table shows example SLE container image tags found on registry.suse.com .Some tags are regularly updated, so they do not annotate the exact image version. Instead theyact as placeholders. The regularly updated tags are marked in bold.

TABLE 3.2: EXAMPLES OF CURRENTLY USED TAGS

Repository name: Tag Description

suse/sle12sp3: latest Latest published image of SUSE Linux Enter-prise 12 SP3.

suse/sle12sp3: 2.0.2 Same as latest . Only kept for back-wards-compatibility.

8 Tags SLES 15 SP2

suse/sle15: latest Latest published image of the SUSE LinuxEnterprise 15 codestream. Same as 15.1 and15.1.1.1 in this example.

suse/sle15: 15.1 Latest published image of SLE 15 SP1.

suse/sle15: 15.1.1.1 Same as 15.1.1.0, but contains some updatedpackages.

suse/sle15: 15.1.1.0 First SUSE Linux Enterprise 15 SP1 image.

3.3 SUSE RegistryThe official SUSE Registry is available at https://registry.suse.com . It contains tested and up-dated SUSE Linux Enterprise and SLES base container images. All images in the SUSE Registryundergo a xed maintenance process. The images are regularly updated with the latest securi-ty fixes. While the SUSE Registry can be used free of charge, if offers additional functionalitythrough a customer subscription on the container host. A subscription is required for the con-tainer images to receive updates. Currently, the SUSE Registry does not have a UI or a list ofimages. However, all available images are listed in the examples in the Book “Docker Open Source

Engine Guide”, Chapter 4 “Creating Custom Images”, Section 4.1 “Obtaining Base SLES Images”.

3.4 Comparing ContainersThe container-di (https://github.com/GoogleContainerTools/container-diff#container-di) toolcan be used for analyzing and comparing container images. container-diff can examineimages along several different criteria, including the following:

Docker Image History

Image le system

DEB packages

RPM packages

PyPI packages

NPM packages

9 SUSE Registry SLES 15 SP2

You can inspect a single image, or perform a di operation on two images. container-diffsupports Docker images located in both a local Docker daemon and a remote registry. It is alsopossible to use the tool with the .tar , .tar.gz , and .tgz archives.

The container-diff package is part of the SUSE Linux Enterprise Server 15 SP2 Contain-ers Module. Alternatively, it can be installed separately. For instructions on installing it, seethe container-di documentation (https://github.com/GoogleContainerTools/container-diff#instal-

lation) .

3.5 On-Premises Registry

3.5.1 Portus

Portus (http://port.us.org/) is an on-premises application that provides a graphical interfaceand an authorization mechanism for Docker registries. For a more detailed description of Portusfunctionality, see http://port.us.org/features.html .

Portus can be deployed using a standard Docker container, inside a Kubernetes cluster, or onbare metal. For deployment options and instructions on how to get started with Portus in adevelopment environment, see http://port.us.org/docs/deploy.html .

For instructions on how to install Portus from the SUSE Container Registry, see Book “Docker

Open Source Engine Guide”, Chapter 3 “Storing Images”, Section 3.4 “Portus”.

10 On-Premises Registry SLES 15 SP2

4 Support Plans

This chapter explains how SLES container support plans work.

There are three guiding principles of SUSE container support.

1. The container image lifecycle follows the lifecycle of the related products.For example, SLES 15 SP2 container images follow the SLES 15 SP2 lifecycle.

2. Container release status also matches the status of the related product.For example, if SLES 15 SP2 is in Alpha, Beta, RC or GA stage, the related containers havethe same release status.

3. Containers are built using the packages from the related products.For example, SLES 15 SP2 container images are built using the same packages as the mainSLES 15 SP2 release.

4.1 Supported Containers on SUSE HostEnvironmentsThe following support options (tiers) apply to SUSE Linux Enterprise Server and SUSE CaaSPlatform containers on SUSE host environments.

4.1.1 Tier One

Containers Delivered by SUSE

Containers delivered by SUSE are fully supported. This applies to both the containerand host environment as well as all products under support. This includes both generalsupport and Long Term Service Pack Support (https://www.suse.com/products/long-term-ser-

vice-pack-support/) (LTSS).

4.1.2 Tier Two

Containers Delivered by Partners with an Agreement Ensuring a Joint Engineering Collaboration

11 Supported Containers on SUSE Host Environments SLES 15 SP2

This tier targets important Independent Software Vendors (ISVs). Partner containers witha joint engineering collaboration agreement are fully supported. This applies to both thecontainer and host environment as well as all products under support (both general, aswell as LTSS) covered by the agreement. Products not covered by the agreement fall underTier Three.

4.1.3 Tier Three

All Other Third-Party Containers

The SUSE container host environment is fully supported. However the container vendor isresponsible for handling issues related to third-party containers they maintain.

4.2 Supported Container Host EnvironmentsThe support options (tiers) covered below apply to the following container options:

SUSE Linux Enterprise base containers

Containers delivered by SUSE

Third-party container environments derived from the SLE base containers

Third-party containers built from SLE packages using KIWI

4.2.1 Tier One

SUSE Products

This tier applies to SUSE Linux Enterprise Server, SUSE CaaS Platform and SUSE CloudApplication Platform. Both the containers and host environments delivered by SUSE arefully supported as well as all products under support. This includes both general supportand LTSS.

4.2.2 Tier Two

Third-Party Vendors with an Agreement Ensuring a Joint Engineering Collaboration

12 Tier Three SLES 15 SP2

Partner containers and host environments with a joint engineering collaboration agree-ment are fully supported. This applies to both the container and host environment as wellas all products under support (both general and LTSS) covered by the agreement.

4.2.3 Tier Three

Selected Third-Party Vendors with No Agreement

This tier targets environments delivered by RHEL, OpenShift or Ubuntu. While SUSE-basedcontainers are fully supported, issues in the host environment must be handled by the hostenvironment vendor. SUSE supports components that come from the SUSE base containers.Packages from SUSE repositories are also supported. Additional components and applica-tion in the containers are not covered by SUSE support. A SLE subscription is required forbuilding a derived container.

4.2.4 Tier Four

Any Other Container Host Environment

Any container host environment not mentioned in the support tiers above has limitedsupport. Details can be discussed with the SUSE Support Team, who might triage the issueand recommend alternative solutions. In any other case, issues in the host environmentmust be handled by the host environment vendor.

13 Tier Three SLES 15 SP2

A GNU LicensesThis appendix contains the GNU Free Docu-mentation License version 1.2.

GNU Free Documentation License

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor,Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copiesof this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and usefuldocument "free" in the sense of freedom: to assure everyone the effective freedom to copyand redistribute it, with or without modifying it, either commercially or non-commercially.Secondarily, this License preserves for the author and publisher a way to get credit for theirwork, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document mustthemselves be free in the same sense. It complements the GNU General Public License, whichis a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, because free softwareneeds free documentation: a free program should come with manuals providing the samefreedoms that the software does. But this License is not limited to software manuals; it canbe used for any textual work, regardless of subject matter or whether it is published as aprinted book. We recommend this License principally for works whose purpose is instructionor reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placedby the copyright holder saying it can be distributed under the terms of this License. Such anotice grants a world-wide, royalty-free license, unlimited in duration, to use that work underthe conditions stated herein. The "Document", below, refers to any such manual or work. Anymember of the public is a licensee, and is addressed as "you". You accept the license if youcopy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portionof it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document thatdeals exclusively with the relationship of the publishers or authors of the Document to theDocument's overall subject (or to related matters) and contains nothing that could fall directlywithin that overall subject. (Thus, if the Document is in part a textbook of mathematics, aSecondary Section may not explain any mathematics.) The relationship could be a matterof historical connection with the subject or with related matters, or of legal, commercial,philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as beingthose of Invariant Sections, in the notice that says that the Document is released under thisLicense. If a section does not t the above definition of Secondary then it is not allowed to bedesignated as Invariant. The Document may contain zero Invariant Sections. If the Documentdoes not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts orBack-Cover Texts, in the notice that says that the Document is released under this License. AFront-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a for-mat whose specification is available to the general public, that is suitable for revising the doc-ument straightforwardly with generic text editors or (for images composed of pixels) genericpaint programs or (for drawings) some widely available drawing editor, and that is suitablefor input to text formatters or for automatic translation to a variety of formats suitable forinput to text formatters. A copy made in an otherwise Transparent le format whose markup,or absence of markup, has been arranged to thwart or discourage subsequent modificationby readers is not Transparent. An image format is not Transparent if used for any substantialamount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Tex-info input format, LaTeX input format, SGML or XML using a publicly available DTD, and stan-dard-conforming simple HTML, PostScript or PDF designed for human modification. Examplesof transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary

formats that can be read and edited only by proprietary word processors, SGML or XML forwhich the DTD and/or processing tools are not generally available, and the machine-generat-ed HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages asare needed to hold, legibly, the material this License requires to appear in the title page. Forworks in formats which do not have any title page as such, "Title Page" means the text near themost prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is preciselyXYZ or contains XYZ in parentheses following text that translates XYZ in another language.(Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements","Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section whenyou modify the Document means that it remains a section "Entitled XYZ" according to thisdefinition.

The Document may include Warranty Disclaimers next to the notice which states that thisLicense applies to the Document. These Warranty Disclaimers are considered to be includedby reference in this License, but only as regards disclaiming warranties: any other implicationthat these Warranty Disclaimers may have is void and has no effect on the meaning of thisLicense.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or non-commercially, provided that this License, the copyright notices, and the license notice sayingthis License applies to the Document are reproduced in all copies, and that you add no otherconditions whatsoever to those of this License. You may not use technical measures to obstructor control the reading or further copying of the copies you make or distribute. However, youmay accept compensation in exchange for copies. If you distribute a large enough number ofcopies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publiclydisplay copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of theDocument, numbering more than 100, and the Document's license notice requires Cover Texts,you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts:Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both coversmust also clearly and legibly identify you as the publisher of these copies. The front covermust present the full title with all words of the title equally prominent and visible. You mayadd other material on the covers in addition. Copying with changes limited to the covers, aslong as they preserve the title of the Document and satisfy these conditions, can be treatedas verbatim copying in other respects.

If the required texts for either cover are too voluminous to t legibly, you should put therst ones listed (as many as t reasonably) on the actual cover, and continue the rest ontoadjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, youmust either include a machine-readable Transparent copy along with each Opaque copy, orstate in or with each Opaque copy a computer-network location from which the general net-work-using public has access to download using public-standard network protocols a completeTransparent copy of the Document, free of added material. If you use the latter option, youmust take reasonably prudent steps, when you begin distribution of Opaque copies in quanti-ty, to ensure that this Transparent copy will remain thus accessible at the stated location untilat least one year after the last time you distribute an Opaque copy (directly or through youragents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well beforeredistributing any large number of copies, to give them a chance to provide you with anupdated version of the Document.

14 SLES 15 SP2

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions ofsections 2 and 3 above, provided that you release the Modified Version under precisely thisLicense, with the Modified Version filling the role of the Document, thus licensing distributionand modification of the Modified Version to whoever possesses a copy of it. In addition, youmust do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of theDocument, and from those of previous versions (which should, if there were any,be listed in the History section of the Document). You may use the same title as aprevious version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible forauthorship of the modifications in the Modified Version, together with at least veof the principal authors of the Document (all of its principal authors, if it has fewerthan ve), unless they release you from this requirement.

C. State on the Title page the name of the publisher of the Modified Version, as thepublisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the othercopyright notices.

F. Include, immediately after the copyright notices, a license notice giving the publicpermission to use the Modified Version under the terms of this License, in the formshown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required CoverTexts given in the Document's license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled "History", Preserve its Title, and add to it an itemstating at least the title, year, new authors, and publisher of the Modified Versionas given on the Title Page. If there is no section Entitled "History" in the Document,create one stating the title, year, authors, and publisher of the Document as givenon its Title Page, then add an item describing the Modified Version as stated inthe previous sentence.

J. Preserve the network location, if any, given in the Document for public access toa Transparent copy of the Document, and likewise the network locations given inthe Document for previous versions it was based on. These may be placed in the"History" section. You may omit a network location for a work that was publishedat least four years before the Document itself, or if the original publisher of theversion it refers to gives permission.

K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Titleof the section, and preserve in the section all the substance and tone of each of thecontributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text andin their titles. Section numbers or the equivalent are not considered part of thesection titles.

M. Delete any section Entitled "Endorsements". Such a section may not be includedin the Modified Version.

N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict intitle with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Se-condary Sections and contain no material copied from the Document, you may at your optiondesignate some or all of these sections as invariant. To do this, add their titles to the list ofInvariant Sections in the Modified Version's license notice. These titles must be distinct fromany other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorse-ments of your Modified Version by various parties--for example, statements of peer reviewor that the text has been approved by an organization as the authoritative definition of astandard.

You may add a passage of up to ve words as a Front-Cover Text, and a passage of up to 25words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Onlyone passage of Front-Cover Text and one of Back-Cover Text may be added by (or througharrangements made by) any one entity. If the Document already includes a cover text for thesame cover, previously added by you or by arrangement made by the same entity you areacting on behalf of, you may not add another; but you may replace the old one, on explicitpermission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to usetheir names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, underthe terms defined in section 4 above for modified versions, provided that you include in thecombination all of the Invariant Sections of all of the original documents, unmodified, andlist them all as Invariant Sections of your combined work in its license notice, and that youpreserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invari-ant Sections may be replaced with a single copy. If there are multiple Invariant Sections withthe same name but different contents, make the title of each such section unique by addingat the end of it, in parentheses, the name of the original author or publisher of that section ifknown, or else a unique number. Make the same adjustment to the section titles in the list ofInvariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various originaldocuments, forming one section Entitled "History"; likewise combine any sections Entitled"Acknowledgements", and any sections Entitled "Dedications". You must delete all sectionsEntitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released underthis License, and replace the individual copies of this License in the various documents with asingle copy that is included in the collection, provided that you follow the rules of this Licensefor verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually underthis License, provided you insert a copy of this License into the extracted document, and followthis License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent docu-ments or works, in or on a volume of a storage or distribution medium, is called an "aggregate"if the copyright resulting from the compilation is not used to limit the legal rights of the com-pilation's users beyond what the individual works permit. When the Document is included inan aggregate, this License does not apply to the other works in the aggregate which are notthemselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, thenif the Document is less than one half of the entire aggregate, the Document's Cover Textsmay be placed on covers that bracket the Document within the aggregate, or the electronicequivalent of covers if the Document is in electronic form. Otherwise they must appear onprinted covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of theDocument under the terms of section 4. Replacing Invariant Sections with translations requiresspecial permission from their copyright holders, but you may include translations of someor all Invariant Sections in addition to the original versions of these Invariant Sections. Youmay include a translation of this License, and all the license notices in the Document, andany Warranty Disclaimers, provided that you also include the original English version of thisLicense and the original versions of those notices and disclaimers. In case of a disagreementbetween the translation and the original version of this License or a notice or disclaimer, theoriginal version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", therequirement (section 4) to Preserve its Title (section 1) will typically require changing theactual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly pro-vided for under this License. Any other attempt to copy, modify, sublicense or distribute theDocument is void, and will automatically terminate your rights under this License. However,parties who have received copies, or rights, from you under this License will not have theirlicenses terminated so long as such parties remain in full compliance.

15 SLES 15 SP2

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documen-tation License from time to time. Such new versions will be similar in spirit to the presentversion, but may differ in detail to address new problems or concerns. See http://www.gnu.org/

copyleft/ .

Each version of the License is given a distinguishing version number. If the Document specifiesthat a particular numbered version of this License "or any later version" applies to it, you havethe option of following the terms and conditions either of that specified version or of anylater version that has been published (not as a draft) by the Free Software Foundation. If theDocument does not specify a version number of this License, you may choose any version everpublished (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

Copyright (c) YEAR YOUR NAME.Permission is granted to copy, distribute and/or modify this documentunder the terms of the GNU Free Documentation License, Version 1.2or any later version published by the Free Software Foundation;with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.A copy of the license is included in the section entitled “GNUFree Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the“with...Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, with theFront-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three,merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasingthese examples in parallel under your choice of free software license, such as the GNU GeneralPublic License, to permit their use in free software.

16 SLES 15 SP2