Jump to content

Getting Started with SUSE Manager for Retail

Publication Date: 2019-09-20

1 Introduction

1.1 What is SUSE Manager for Retail?

SUSE Manager for Retail 3.2 is an open source infrastructure management solution, optimized and tailored specifically for the retail industry. It uses the same technology as SUSE Manager, but is customized to address the needs of retail organizations.

SUSE Manager for Retail is designed for use in retail situations where customers can use point-of-service terminals to purchase or exchange goods, take part in promotions, or collect loyalty points. In addition to retail installations, it can also be used for novel purposes, such as maintaining student computers in an educational environment, or self-service kiosks in banks or hospitals.

SUSE Manager for Retail is intended for use in installations that include servers, workstations, point-of-service terminals, and other devices. It allows administrators to install, configure, and update the software on their servers, and manage the deployment and provisioning of point-of-service machines.

Important
Important

Migrating configuration from SUSE Linux Enterprise Point of Service to SUSE Manager for Retail is a technology preview and will be enhanced in future releases of SUSE Manager.

1.2 About this book

This document provides an overview of SUSE Manager for Retail, and guides you through initial installation and setup. It should be read in conjunction with the SUSE Manager documentation suite, available from https://www.suse.com/documentation/suse-manager-3/

For more information about managing your SUSE Manager for Retail environment, or to find out where to get help, see https://www.suse.com/documentation/suse-manager-for-retail-3-2/retail-getting-started/retail.chap.next.html

2 Components

2.1 Components

SUSE Manager for Retail uses a layered architecture:

  • The first layer contains the SUSE Manager server and one or more build hosts.

  • The second layer contains one or more branch servers to provide local network and boot services.

  • The final layer contains any number of deployed point-of-service terminals.

retail ref arch

2.1.1 SUSE Manager Server

The SUSE Manager server contains information about infrastructure, network topology, and everything required to automate image deployment and perform day-to-day operations on branches and terminals. This can include database entries of registered systems, Salt pillar data for images, image assignments, partitioning, network setup, network services, and more.

2.1.2 Build Hosts

Build hosts can be arbitrary servers or virtual machines. They are used to securely build operating system images. Build hosts should be based on SUSE Linux Enterprise Server 12 SP3.

2.1.3 Branch Server

Branch servers should be physically located close to point-of-service terminals, such as in an individual store or branch office. We recommend you have a fast network connection between the branch server and its terminals. Branch servers provide services for PXE boot, and act as an image cache, Salt broker, and proxy for software components (RPM packages). The branch server can also manage local networking, and provide DHCP and DNS services.

The branch server can operate in several different network configurations:

  • The branch server has a dedicated network interface card and terminals use an isolated internal branch network. In this configuration, the branch server manages the internal network and provides DHCP, DNS, PXE, FTP, and TFTP services.

  • The branch server shares a network with the terminals, and provides a connection to the SUSE Manager server. In this configuration, the branch server is not required to manage a network (DHCP and DNS services), but acts as a PXE boot server and provides FTP and TFTP services.

For more information on SUSE Manager for Retail Branch servers, see documentation on SUSE Manager Proxy servers.

2.1.4 Point-of-Service Terminals

Point-of-Service (PoS) terminals can come in many different formats, such as point-of-sale terminals, kiosks, digital scales, self-service systems, and reverse-vending systems. Every terminal, however, is provided by a vendor, who set basic information about the device in the firmware. SUSE Manager for Retail accesses this vendor information to determine how best to work with the terminal in use.

In most cases, different terminals will require a different operating system (OS) image to ensure they work correctly. For example, an information kiosk has a high-resolution touchscreen, where a cashier terminal might only have a very basic display. While both of these terminals require similar processing and network functionality, they will require different OS images to ensure that the different display mechanisms work correctly.

The minimum memory requirement is 1024 MB for hosts that need to run OS images built with Kiwi (PXE booted or not)

Hardware Requirements for PoS Terminals: . At least 1 GB of RAM. For more information, see the documentation of the underlying system (in this case: SUSE Linux Enterprise Server 12). . Enough disk space depending on the image size.

For more information on SUSE Manager for Retail PoS terminals, see documentation on SUSE Manager Salt clients.

2.2 Fitting it all together

SUSE Manager for Retail uses the same technology as SUSE Manager, but is customized to address the needs of retail organizations.

2.2.1 Hardware types

Because every environment is different, and can contain many different configurations of many different terminals, SUSE Manager for Retail uses hardware types to simplify device management.

Hardware types allow you to group devices according to manufacturer and device name, so that all devices of a particular type can be managed as one.

2.2.2 Salt formulas

SUSE Manager for Retail uses Salt formulas to help simplify configuration. Formulas are pre-written Salt states, that are used to configure your installation.

You can use formulas to apply configuration patterns to your hardware groups. SUSE Manager for Retail uses the Saltboot formula, which defines partitioning and OS images for terminals.

You can use default settings for formulas, or edit them to make them more specific to your environment.

Formulas are discussed in more detail in this guide, at Formulas Chapter.

2.2.3 System groups

SUSE Manager for Retail uses system groups to organize the various devices in your environment.

Each branch requires a system group, containing a single branch server, and the PoS terminals associated with that server. Each system group is identified with a Branch ID, which is used in formulas and scripts to automatically update the entire group.

3 Installation

3.1 Requirements

Before you install SUSE Manager for Retail, ensure your environment meets the minimum requirements. This section lists the requirements for your SUSE Manager for Retail installation. These requirements are in addition to the SUSE Manager requirements listed at https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-getting-started/html/book.suma.getting-started/quickstart.chapt.overview.requirements.html#quickstart.sect.prereq

Important
Important

SUSE Manager for Retail is only supported on x86_64 architecture.

Table 3.1: Hardware Requirements for SUSE Manager server
HardwareRecommended

CPU

Multi-core 64-bit CPU

RAM:

Test Server Minimum 8 GB

 

Base Installation Minimum 16 GB

 

Production Server Minimum 32 GB

Disk Space:

/ (root) 100 GB

 

/var/lib/pgsql Minimum 50 GB

 

/srv/ 50 GB (Minimum 2 GB per OS image)

 

/var/spacewalk Minimum 50 GB per SUSE product and 250 GB per Red Hat product

Table 3.2: Hardware requirements for build host

Hardware

Recommended

CPU

Multi-core 64-bit CPU

RAM:

4 GB

Disk Space:

/ (root) 50 GB

Table 3.3: Hardware requirements for branch server

Hardware

Recommended

CPU

Multi-core 64-bit CPU

RAM:

8 GB

Disk Space:

/ (root) 100 GB (Minimum 50 GB per SUSE product and 2 GB per OS image)

Network Requirements
  • The SUSE Manager server requires a reliable and fast WAN connection

  • The branch server requires a reliable WAN connection, to reach the SUSE Manager server

  • If you are using a shared network, ensure that DHCP requests are filtered before reaching the rest of your shared network

  • If you are using a dedicated network, the branch server requires at least two network interfaces: one connected to the WAN with reachable SUSE Manager server, and one connected to the internal branch LAN.

  • Terminals require a LAN connection to the branch server network.

3.2 Installation

SUSE Manager for Retail can be installed in various ways depending on individual needs. We recommend these steps:

  1. Install the SUSE Manager server

  2. Configure the SUSE Manager server

  3. Install the SUSE Manager for Retail pattern on the SUSE Manager server

  4. Install the build host and register it to SUSE Manager

  5. Configure the build host

  6. Create required system group

Branch server installation steps:

  1. Install the branch server and register it to SUSE Manager

  2. Assign and configure branch server formulas

  3. Synchronize images to the servers

Each procedure is detailed in this section.

3.2.1 Install the SUSE Manager server

For instructions to install SUSE Manager, see the https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-getting-started/html/book.suma.getting-started/quickstart.chapt.overview.requirements.html#quickstart.sect.introduction

Warning
Warning: Do Not Enable PXE Boot

Do not enable PXE boot functionality on the SUSE Manager Proxy during initial setup. This functionality will be installed later, after the initial setup.

3.2.2 Configure the SUSE Manager server

It is important that all required SUSE channels are available on your system and synchronized in order for SUSE Manager for Retail to operate correctly. For more information on channel management, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-advanced-topics/html/book.suma.advanced.topics/suse.mgr.command.line.tools.html#syncing.suse.mgr.repositories.scc

Channels required for SUSE Manager for Retail functionality:

- SLES 12 SP3 (SP4 in the future) as a base
  - SLES Pool
    - SLES Update
- SUSE Manager 3.2 Tools
  - SUSE Manager 3.2 Tools Pool
    - SUSE Manager 3.2 Tools Update
- SUSE Manager 3.2 Proxy
  - SUSE Manager 3.2 Proxy Pool
    - SUSE Manager 3.2 Proxy Update
- SUSE Manager 3.2 Proxy for Retail
  - SUSE Manager 3.2 Proxy for Retail Pool
    - SUSE Manager 3.2 Proxy for Retail Update

After you have synchronized the required SUSE channels, create channels for any custom software. Channels are used to provide custom software for OS image building. For more information on software channels, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-reference/html/book.suma.reference.manual/ref.webui.channels.html

3.2.3 Install the SUSE Manager for Retail pattern on the SUSE Manager server

Procedure: Installing the SUSE Manager for Retail pattern on the SUSE Manager server
  1. Install the SUSE Manager for Retail pattern on the SUSE Manager server:

    zypper in -t pattern suma_retail
  2. Check that you have these packages installed and available, after installing SUSE Manager and SUSE Manager for Retail pattern:

    • bind-formula

    • branch-network-formula

    • dhcpd-formula

    • image-sync-formula

    • pxe-formula

    • saltboot-formula

    • susemanager-retail-tools

    • tftpd-formula

    • vsftpd-formula

      Install any missing packages with zypper:

      zypper install package_name
  3. Synchronize the salt filesystem and salt modules:

    salt-run fileserver.update
    salt '*' saltutil.sync_all
  4. Restart the salt master service to pick up the changes:

    Restart salt master service now.
    
    systemctl restart salt-master

For more information about formulas, see Formulas.

3.2.4 Install the build host and register it to SUSE Manager

Your build host should be a Salt minion, running SUSE Linux Enterprise Server 12 SP3. For instructions to install Salt minion see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-getting-started/html/book.suma.getting-started/preparing.and.registering.clients.html

Warning
Warning

The build host must be a Salt minion. Do not install the build host as a traditionally managed client.

3.2.5 Configure the build host

The build host must be set as an OS Image build host in the SUSE Manager Web UI, and highstate applied.

Procedure: Configuring the build host
  1. In the SUSE Manager Web UI, navigate to SystemsOverview. Locate the system to be made a build host, and click on its name.

  2. In the System Properties window, click Edit These Properties.

  3. In the Edit System Details window, ensure the OS Image Build Host option is checked, and click Update Properties to save your changes.

  4. Select the States tab, and navigate to the Highstate window.

  5. In the States tab, click Apply Highstate.

Important
Important

Check that the build host has these packages installed after you have run Highstate:

  • kiwi

  • kiwi-desc-saltboot

If any package is missing, make sure the SUSE Manager 3.2 Tools repository is available on the build host and install any missing packages manually using zypper install.

3.2.6 Create required system groups

SUSE Manager for Retail requires system groups for terminals and servers. Manually create these system groups during installation:

  • TERMINALS

  • SERVERS

Additionally, you will need to create a system group for each branch server, and each terminal hardware type in your environment.

You can create system groups using the SUSE Manager Web UI. Navigate to SystemsSystem Groups and click on Create System Group.

For more information about system groups, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-reference/html/book.suma.reference.manual/ref.webui.systems.systems.html#ref.webui.systems.systemgroups

3.2.7 Install the branch server and register it to SUSE Manager

Your branch server should be installed as a default Salt-based client ("minion"), running SUSE Manager Proxy 3.2.

Warning
Warning

Do not install the branch server as a traditionally managed client.

For instructions to install Salt-based proxy minions and register them to SUSE Manager, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-advanced-topics/html/book.suma.advanced.topics/advanced.topics.proxy.quickstart.html

The activation key should have the following channels:

- SLES 12 SP3 (SP4 in the future) as a base
  - SLES Pool
    - SLES Update
- SUSE Manager 3.2 Tools
  - SUSE Manager 3.2 Tools Pool
    - SUSE Manager 3.2 Tools Update
- SUSE Manager 3.2 Proxy
  - SUSE Manager 3.2 Proxy Pool
    - SUSE Manager 3.2 Proxy Update
- SUSE Manager 3.2 Proxy for Retail
  - SUSE Manager 3.2 Proxy for Retail Pool
    - SUSE Manager 3.2 Proxy for Retail Update

For mass deployments, see Branch Server Mass Configuration.

When you are installing the branch server with a dedicated internal network, check that you are using the same fully qualified domain name (FQDN) on both the external and internal branch networks. If the FQDN does not match on both networks, the branch server will not be recognized as a proxy server.

3.2.8 Assign and configure branch server formulas

Before you configure the branch server, ensure you have decided on networking topology, and know the Salt ID of the branch server.

The branch server can be configured automatically using the retail_branch_init command, as shown in this section. If you prefer to manually configure the branch server, you can do so using formulas. For more information about formulas, see Formulas.

Procedure: Configuring branch server formulas using helper script
  1. Branch server configuration is performed using the retail_branch_init command:

    retail_branch_init <branch_server_salt_id>

    This command will configure branch server formulas with recommended values. You can use the retail_branch_init --help command for additional options.

  2. Verify that your changes have been configured correctly by checking the SUSE Manager Web UI branch server system formulas.

  3. Apply highstate on the branch server. You can do this through the Web UI, or by running this command:

    salt <branch_server_salt_id> state.apply

3.2.9 Synchronize images to the servers

The OS image you use on the SUSE Manager server must be synchronized for use on the branch server. You can do this with the Salt image-sync tool.

Procedure: Synchronize images with branch server
  1. On the branch server, run this command:

    salt <branch_server_salt_id> state.apply image-sync
  2. The image details will be transferred to /srv/saltboot on the branch server.

4 Formulas

Formulas are pre-written Salt states, that are used to configure your SUSE Manager for Retail installation.

This section lists the primary formulas shipped with SUSE Manager for Retail and their configuration options.

All the formulas in this section must be accurately configured for your SUSE Manager for Retail installation to function correctly. If you are unsure of the correct formula configuration details, run the retail_branch_init command before you begin to create the recommended formula configuration. You can then manually edit the formulas as required.

Important
Important: State and formula name collisions

If a formula uses the same name as an existing Salt state, the two names will collide, and could result in the formula being used instead of the state. Always check the names of states and formulas to avoid name collisions.

Most formulas can be updated using the SUSE Manager Web UI. Once you have made changes to your formula, ensure you apply the highstate to propagate your changes to the appropriate services.

4.1 Bind Formula

The Bind formula is used to configure the Domain Name System (DNS) on the branch server. POS terminals will use the DNS on the branch server for name resolution of saltboot specific hostnames.

When you are configuring the bind formula for a branch server with a dedicated internal network, check that you are using the same fully qualified domain name (FQDN) on both the external and internal branch networks. If the FQDN does not match on both networks, the branch server will not be recognized as a proxy server.

Note
Note

The following procedure outlines a standard configuration with two zones. Adjust it to suit your own environment.

Zone 1 is a regular domain zone. Its main purpose is to resolve saltboot hostnames such as TFTP, FTP, or Salt. It can also resolve the terminal names if configured.

Zone 2 is the reverse zone of Zone 1. Its main purpose is to resolve IP addresses back to hostnames. Zone 2 is primarily needed for the correct determination of the FQDNs of the branch.

Procedure: Configuring Bind with Two Zones
  1. Check the Bind formula, and click Save.

  2. Navigate to the FormulasBind tab, and set these parameters for Zone 1:

    • In the Config section, select Include Forwarders.

    • In the Name field, enter the domain name of your branch network (for example: branch1.example.org).

    • In the Type field, select master.

  3. Click Add item to save your changes.

  4. Set these parameters for Zone 2:

    • In the Name field, use the reverse zone for the configured IP range (for example: 1.168.192.in-addr.arpa).

    • In the Type field, select master

  5. In the Available Zones section, use these parameters for Zone 1:

    • In the Name field, enter the domain name of your branch network (for example: branch1.example.org).

    • In the File field, type the name of your configuration file.

  6. In the Start of Authority (SOA) section, use these parameters for Zone 1:

    • In the Nameserver (Ns) field, use the FQDN of the branch server (for example: branchserver.branch1.example.org).

    • In the Contact field, use the email address for the domain administrator.

    • Keep all other fields as their default values.

  7. In the Records section, in subsection A, click Add Item and use these parameters to set up an A record for Zone 1:

    • In the Hostname field, use the hostname of the branch server (for example: branchserver).

    • In the IP field, use the IP address of the branch server (for example, 192.168.1.1).

  8. In the Records section, subsection NS, click Add Item and use these parameters to set up an NS record for Zone 1:

    • In the input box, use the hostname of the branch server (for example: branchserver).

  9. In the Records section, subsection CNAME, click on Add Item and add the hostname of the branch server in each of these fields:

    • tftp

    • ftp

    • dns

    • dhcp

    • salt. The salt CNAME should be the FQDN of the branch server’s external interface for proxy functionality to work correctly.

  10. Set up Zone 2 using the same parameters as for Zone 1, but ensure you use the reverse details:

    • The same SOA section as Zone 1.

    • Empty A and CNAME records.

    • Additionally, configure in Zone 2:

      • Generate Reverse field by the network IP address set in branch server network formula (for example, 192.168.1.1/24).

      • For Zones should specify the domain name of your branch network (for example, branch1.example.org).

  11. Click Save Formula to save your configuration.

  12. Apply the highstate.

Important
Important

Reverse name resolution on terminals might not work for networks that are inside one of these IPv4 private address ranges:

  • 10.0.0.0/8

  • 172.16.0.0/12

  • 192.168.0.0/16

If you encounter this problem, go to the Options section of the Bind formula, and click Add item: * In the Options field, enter empty-zones-enable. * In the Value field, select No.

4.2 Branch Network Formula

The branch network formula is used to configure the networking services required by the branch server, including DHCP, DNS, TFTP, PXE, and FTP.

The branch server can be configured to use networking in many different ways. The most common ways provide either a dedicated or shared LAN for terminals.

4.2.1 Set up a branch server with a dedicated LAN

In this configuration, the branch server requires at least two network interfaces: one acts as a WAN to communicate with the SUSE Manager server, and the other one acts as an isolated LAN to communicate with terminals.

This configuration allows for the branch server to provide DHCP, DNS, TFTP, PXE and FTP services to terminals, which are configured through SUSE Manager for Retail formulas in the SUSE Manager Web UI.

Procedure: Setting up a branch server with a dedicated LAN
  1. In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.

  2. In the Branch Network section, set these parameters:

    • Keep Dedicated NIC checked

    • In the NIC field, enter the name of the network device that is connected to the internal LAN.

    • In the IP field, enter the static IP address to be assigned to the branch server on the internal LAN.

    • In the Netmask field, enter the network mask of the internal LAN.

  3. Check Enable Route if you want the branch server to route traffic from internal LAN to WAN.

    • Check Enable NAT if you want the branch server to convert addresses from internal LAN to WAN.

    • Select the bind DNS forwarder mode.

    • Check DNS forwarder fallback if you want to rely on an external DNS if the branch DNS fails.

    • Specify the working directory, and the directory owner and group.

  4. Click Save to save your changes.

  5. Apply the highstate.

4.2.2 Set up a branch server with a shared network

In this configuration, the branch server has only one network interface card, which is used to connect to the SUSE Manager server as well as the terminals.

This configuration allows for the branch server to provide DNS, TFTP, PXE and FTP services to terminals, which are configured through SUSE Manager for Retail formulas in the SUSE Manager Web UI. Optionally, the branch server can also provide DHCP services in this configuration.

Note
Note

If DHCP services are not provided by the branch server, ensure that your external DHCP configuration is set correctly:

  • The next-server option must point to the branch server for PXE boot to work

  • The filename option must correctly identify the network boot program (by default, this is /boot/pxelinux)

  • The domain-name-servers option must point to the branch server for correct host name resolution

Procedure: Setting up a branch server with a shared network
  1. In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.

  2. In the Branch Network section, set these parameters:

    • Keep Dedicated NIC unchecked

    • Select which services to enable on the branch server’s firewall. Ensure you include DNS, TFTP and FTP services.

    • Select the bind DNS forwarder mode.

    • Check DNS forwarder fallback if you want to rely on an external DNS if the branch DNS fails.

    • Specify the working directory, and the directory owner and group.

  3. Click Save to save your changes.

  4. Apply the highstate.

4.3 DHCPd Formula

The DHCPd formula is used to configure the DHCP service on the branch server.

Procedure: Configuring DHCP
  1. In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.

  2. Select the Dhcpd formula, and click Save.

  3. Navigate to the FormulasDhcpd tab, and set these parameters:

    • In the Domain Name field, enter the domain name for the branch server (for example: branch1.example.com).

    • In the Domain Name Server field, enter either the IP address or resolvable FQDN of the branch DNS server (for example: 192.168.1.1).

    • In the Listen Interfaces field, enter the name of the network interface used to connect to the local branch network (for example: eth1).

  4. Navigate to the Network Configuration (subnet) section, and use these parameters for Network1:

    • In the Network IP field, enter the IP address of the branch server network (for example: 192.168.1.0).

    • In the Netmask field, enter the network mask of the branch server network (for example: 255.255.255.0).

    • In the Domain Name field, enter the domain name for the branch server network (for example: branch1.example.com).

  5. In the Dynamic IP Range section, use these parameters to configure the IP range to be served by the DHCP service:

    • In the first input box, set the lower bound of the IP range (for example: 192.168.1.51).

    • In the second input box, set the upper bound of the IP range (for example: 192.168.1.151).

  6. In the Broadcast Address field, enter the broadcast IP address for the branch network (for example: 192.168.1.255).

  7. In the Routers field, enter the IP address to be used by routers in the branch server network (for example: 192.168.1.1).

  8. In the Next Server field, enter the hostname or IP address of the branch server (for example: 192.168.1.1).

  9. In the Filename field, keep the default value of /boot/pxelinux.0.

  10. Click Save Formula to save your configuration

  11. Apply the highstate.

4.4 PXE Formula

The PXE formula is used to configure PXE booting on the branch server.

Procedure: Configuring PXE booting
  1. In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.

  2. Select the Pxe formula, and click Save.

  3. Navigate to the FormulasPxe tab, and set these parameters:

    • In the Kernel filename field, keep the default value.

    • In the Initrd filename field, keep the default value.

    • In the Kernel commandline parameters field, keep the default value.

    • In the PXE root directory field, enter the path to the saltboot directory (for example, /srv/saltboot).

    • In the Branch id field, type a name to use as a branch identifier (for example: Branch0001). Use only alphanumeric characters for the branch identifier.

  4. Click Save Formula to save your configuration

  5. Apply the highstate.

4.5 Saltboot Formula

The Saltboot formula is used to configure disk images and partitioning for the selected hardware type.

Important
Important

Saltboot formula is meant to be used as a group formula. Enable and configure saltboot formula for hardware type groups.

Procedure: Configuring the hardware type group with saltboot
  1. Open the details page for your new hardware type group, and navigate to the Formulas tab.

  2. Select the saltboot-formula and click Save.

  3. Navigate to the new FormulasSaltboot tab.

  4. In the Disk 1 section, set these parameters:

    • In the Disk symbolic ID field, enter a custom name for the disk (for example, disk1).

    • In the Device type field, select DISK.

    • In the Disk device field, select the device that corresponds to the device name on the target machine (for example, /dev/sda).

    • In the RAID level field, leave it empty.

    • In the Disk Label field, select gpt.

  5. In the Partition section, set these parameters for Partition 1:

    • In the Partition symbolic ID field, enter a custom name for the partition (for example, p1).

    • In the Partition size field, specify a size for the partition in Mebibytes (MiB).

    • In the Device mount point field, select a location to mount the partition (for example, /data).

    • In the Filesystem format field, select your preferred format (for example, xfs).

    • In the OS Image to deploy field, leave it empty.

    • In the Partition encryption password field, enter a password if you want to encrypt the partition.

    • In the Partition flags field, leave it empty.

  6. In the Partition section, set these parameters for Partition 2:

    • In the Partition symbolic ID field, enter a custom name for the partition (for example, p2).

    • In the Partition size field, specify a size for the partition in Mebibytes (MiB).

    • In the Device mount point field, leave it empty.

    • In the Filesystem format field, select swap.

    • In the OS Image to deploy field, leave it empty.

    • In the Partition encryption password field, enter a password if you want to encrypt the partition.

    • In the Partition flags field, select swap.

  7. In the Partition section, set these parameters for Partition 3:

    • In the Partition symbolic ID field, enter a custom name for the partition (for example, p3).

    • In the Partition size field, leave it empty. This will ensure the partition uses up all remaining space.

    • In the Device mount point field, select /.

    • In the Filesystem format field, leave it empty.

    • In the OS Image to deploy field, enter the name of the image to deploy.

    • In the Image version field, leave it empty. This will ensure you use the latest available version.

    • In the Partition encryption password field, enter a password if you want to encrypt the partition.

    • In the Partition flags field, leave it empty.

  8. Click Save Formula to save your formula.

4.6 TFTPd Formula

The TFTPd formula is used to configure the TFTP service on the branch server.

Procedure: Configuring TFTP
  1. In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.

  2. Select the Tftpd formula, and click Save.

  3. Navigate to the FormulasTftpd tab, and set these parameters:

    • In the Internal Network Address field, enter the IP address of the branch server (for example: 192.168.1.1).

    • In the TFTP Base Directory field, enter the path to the saltboot directory (for example, /srv/saltboot).

    • In the Run TFTP Under User field, enter saltboot.

  4. Click Save Formula to save your configuration.

  5. Apply the highstate.

4.7 VsFTPd Formula

The VsFTPd formula is used to configure the FTP service on the branch server.

Procedure: Configuring VsFTPd
  1. In the SUSE Manager Web UI, open the details page for the branch server, and navigate to the Formulas tab.

  2. Select the Vsftpd formula, and click Save.

  3. Navigate to the FormulasVsftpd tab, and set these parameters:

    • In the Internal Network Address, enter IP address of branch server (for example: 192.168.1.1).

    • All other fields can retain their default values.

  4. Click Save Formula to save your configuration

  5. Apply the highstate.

5 Administration

5.1 Administration

This sections contains notes on administering your SUSE Manager for Retail installation. For general administration tasks, see the SUSE Manager documentation at https://www.suse.com/documentation/suse-manager-3/

5.2 Branch server mass configuration

Branch servers are configured individually using formulas. If you are working in an environment with many branch servers, you might find it easier to configure the terminals automatically with a pre-defined configuration file, rather than configuring each branch server individually.

5.2.1 Configure multiple branch servers

This procedure requires the python-susemanager-retail package, which is provided with SUSE Manager for Retail. Install the python-susemanager-retail package on the SUSE Manager server.

Procedure: Configuring multiple branch servers
  1. Create a YAML file describing the infrastructure you intend to install. An example YAML file is at the end of this chapter, for you to reference.

  2. On a clean SUSE Manager installation, import the YAML file you have created:

    retail_yaml --from-yaml filename.yaml

    You can use the retail_yaml --help command for additional options.

If you need to change your configuration, you can edit the YAML file at any time, and use the retail_yaml --from-yaml command to upload the new configuration.

Use the empty profiles together with activation keys to onboard all the systems of your infrastructure. Use an activation key to assign the channels listed in Configuring Server.

5.3 Deploying terminals

For hardware requirements, see Point-of-Service Terminals.

Before terminals can be deployed, ensure you have prepared a saltboot based OS image. For how to build OS images, see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-advanced-topics/html/book.suma.advanced.topics/at.images.html#at.images.kiwi.

Each terminal requires a specific hardware type, which contains information about the product name and terminal manufacturer. However, the SUSE Manager database does not have this information to begin with. In order to tell SUSE Manager what image to deploy on each terminal, you can set hardware type groups. After you have created your new hardware type group, you can apply the saltboot-formula to the group and configure it for your environment.

After you have registered new terminals, always check the SUSE Manager Web UI to ensure your terminal has connected successfully to the branch server, and you have not connected directly to the SUSE Manager server by mistake.

5.3.1 Create a Hardware Type group

Hardware types allow you to group devices according to manufacturer and device name, so that all devices of a particular type can be managed as one.

You will need to create appropriate hardware types in your system.

Empty profiles can be assigned to a hardware type group either before or after registration. If an empty profile is not assigned to a hardware type group before registration, it will be assigned to group that best matches the product information available to it.

For this procedure, you will require the system manufacturer name and product name for your terminal.

Procedure: Creating a Hardware Type group
  1. Determine the hardware type group name. Prefix the name with HWTYPE:, followed by the system manufacturer name and product name, separated by a hyphen. For example:

    HWTYPE:POSVendor-Terminal1
    Important
    Important

    Only use colons (:), hyphens (-) or underscores (_) in hardware type group names. Spaces and other non-alphanumeric characters will be removed when the name is processed.

  2. In the SUSE Manager Web UI, navigate to SystemsOverview, and click on the Groups tab.

  3. Click the Create new button.

  4. In the Create System Group dialog, create a new system group, using the hardware type group name you created earlier.

5.4 Terminal Names

In the SUSE Manager Web UI, terminals have a standard naming format which allows you to match the physical device with its record. By default, the name uses this format:

BranchName.Manufacturer-ProductName-SerialNumber-MachineID

For example:

B002.TOSHIBA-6140100-41BA03X-c643

You can adjust this behavior by toggling the DISABLE_HOSTNAME_ID and DISABLE_UNIQUE_SUFFIX parameters in the PXE formula settings. For more information about the PXE formula, see PXE Formula.

5.5 Terminal mass configuration

If you are working in an environment with many terminals, you might find it easier to configure the terminals automatically with a pre-defined configuration file, rather than configuring each terminal individually.

In order to do this, you will need to have your infrastructure planned out ahead of time, including the IP addresses, hostnames, and domain names of branch servers and terminals. You will also require the hardware (MAC) addresses of each terminal.

Note
Note

The settings specified in the configuration file cannot always be successfully applied. In cases where there is a conflict, SUSE Manager will ignore the request in the file. This is especially important when designating hostnames. You should always check the details have been applied as expected after using this configuration method.

5.5.1 Configure multiple terminals

Procedure: Configuring multiple terminals
  1. Create a YAML file describing the infrastructure you intend to install, specifying the hardware address for each terminal. An example YAML file is at the end of this chapter, for you to reference.

  2. On a clean SUSE Manager installation, import the YAML file you have created:

    retail_yaml --from-yaml filename.yaml

    You can use the retail_yaml --help command for additional options.

  3. In the SUSE Manager Web UI, check that your systems are listed and displaying correctly, and the formulas you require are available.

  4. Create activation keys for each of your branch servers, connect them using bootstrap, and configure them as proxy servers. For further information on these steps, see the SUSE Manager documentation.

  5. Apply highstate to apply your configuration changes. In the States tab, click Apply Highstate.

  6. Connect your terminals according to your infrastructure plan.

If you need to change your configuration, you can edit the YAML file at any time, and use the retail_yaml --from-yaml command to upload the new configuration.

If you have a current configuration that you would like to export to a YAML file, use:

retail_yaml --to-yaml filename.yaml

This can be a good way to create a basic mass configuration file. However it is important to check the file before using it, as some mandatory configuration entries will be missing.

Important
Important

When you are designing your configuration and creating the YAML file, ensure the branch server ID matches the fully qualified hostname, and the Salt ID. If these do not match, the bootstrap script could fail.

5.6 Example YAML file for mass configuration

You can use the retail_yaml command to import configuration parameters from a pre-prepared YAML file. This section contains a commented example YAML file for you to reference.

Example: YAML mass terminal configuration file. 

branches:
# there are 2 possible setups: with / without dedicated NIC
#
# with dedicated NIC
  branchserver1.branch1.cz:     # salt ID of branch server
    branch_prefix: branch1      # optional, default guessed from salt id
    server_name: branchserver1  # optional, default guessed from salt id
    server_domain: branch1.cz   # optional, default guessed from salt id
    nic: eth1                   # nic used for connecting terminals, default taken from hw info in SUMA
    dedicated_nic: true         # set to true if the terminals are on separate network
    salt_cname: branchserver1.branch1.cz      # hostname of salt master / broker for terminals, mandatory
    configure_firewall: true    # modify firewall configuration
    branch_ip: 192.168.2.1      # default for dedicated NIC: 192.168.1.1
    netmask: 255.255.255.0      # default for dedicated NIC: 255.255.255.0
    dyn_range:                  # default for dedicated NIC: 192.168.1.10 - 192.168.1.250
        - 192.168.2.10
        - 192.168.2.250
# without dedicated NIC
# the DHCP formula is not used, DHCP is typically provided by a router
# the network parameters can be autodetected if the machine is already connected to SUSE Manager
  branchserver2.branch2.cz:     # salt ID of branch server
    branch_prefix: branch2      # optional, default guessed from salt id
    server_name: branchserver2  # optional, default guessed from salt id
    server_domain: branch2.cz   # optional, default guessed from salt id
    salt_cname: branchserver2.branch1.cz      # FQDN of salt master / broker for terminals, mandatory
    branch_ip: 192.168.2.1      # optional, default taken from SUMA data if the machine is registered
    netmask: 255.255.255.0      # optional, default taken from SUMA data if the machine is registered
    exclude_formulas:           # optional, do not configure listed formulas
      - dhcp                    # without dedicated NIC the dhcp service is typically provided by a router
    hwAddress: 11:22:33:44:55:66 # optional, required to connect pre-configured entry with particular machine
                                 # during onboarding
    terminals:                       # configuration of static terminal entries
      hostname1:                     # hostname
        hwAddress: aa:aa:aa:bb:bb:bb # required as unique id of a terminal
        IP: 192.168.2.50             # required for static dhcp and dns entry
        saltboot:                    # optional, alternative 1: configure terminal-specific pillar data
          partitioning:              # partitioning pillar as described in saltboot documentation
            disk1:
              device: /dev/sda
              disklabel: msdos
              partitions:
                p1:
                  flags: swap
                  format: swap
                  size_MiB: 2000.0
                p2:
                  image: POS_Image_JeOS6
                  mountpoint: /
              type: DISK
      hostname2:                     # hostname
        hwAddress: aa:aa:aa:bb:bb:cc # required as unique id of a terminal
        IP: 192.168.2.51             # required for static dhcp and dns entry
        hwtype: IBMCORPORATION-4838910 # optional, alternative 2: assign the terminal to hwtype group
        # if neither of hwtype nor saltboot is specified, a group is assigned according to hwtype
        # reported by bios on the first boot
hwtypes:
  IBMCORPORATION-4838910:      # HWTYPE string (manufacturer-model) as returned by bios
    description: 4838-910       # freetext description
    saltboot:
      partitioning:             # partitioning pillar as described in saltboot documentation
        disk1:
          device: /dev/sda
          disklabel: msdos
          partitions:
            p1:
              flags: swap
              format: swap
              size_MiB: 1000.0
            p2:
              image: POS_Image_JeOS6
              mountpoint: /
          type: DISK
  TOSHIBA-6140100:
    description: HWTYPE:TOSHIBA-6140100
    saltboot:
      partitioning:
        disk1:
          device: /dev/sda
          disklabel: msdos
          partitions:
            p1:
              flags: swap
              format: swap
              size_MiB: 1000.0
            p2:
              image: POS_Image_JeOS6
              mountpoint: /
          type: DISK

6 What next?

6.1 What next?

This document covers only a sub-section of information about your SUSE Manager for Retail installation. If you need further information or support, try one of these options.

6.1.1 More documentation

For SUSE Manager documentation, visit https://www.suse.com/documentation/suse-manager-3/

For legacy SUSE Linux Enterprise Point of Service documentation, visit https://www.suse.com/documentation/slepos11/index.html Note, however, that SUSE Manager for Retail documentation supersedes this information.

6.1.2 Support

For personalized support, log in to your SUSE Customer Center account here: https://scc.suse.com/login

For assistance with planning and installing your SUSE Manager for Retail environment, contact the SUSE Consulting team.

A GNU Licenses

This appendix contains the GNU Free Documentation License version 1.2.

7 GNU Free Documentation License

Copyright © 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 copies of 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 useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, 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 must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, 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 portion of 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 that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of 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 being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does 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 or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-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 format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of 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 for which the DTD and/or processing tools are not generally available, and the machine-generated 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 as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most 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 precisely XYZ 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 when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

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

2. VERBATIM COPYING

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

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

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, 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 covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

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

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

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

4. MODIFICATIONS

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

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, 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 a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

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

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as 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 given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the 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 published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

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

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

  15. Preserve any Warranty Disclaimers.

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

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties—​for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission 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 use their 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, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

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

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

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for 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 under this License, provided you insert a copy of this License into the extracted document, and follow this 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 documents 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 compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

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

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

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document 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 their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, 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 specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (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 document
   under the terms of the GNU Free Documentation License, Version 1.2
   or 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{ldquo}GNU
   Free Documentation License{rdquo}.

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 the
   Front-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 releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

Print this page